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Abstract 


This  paper  documents  research  into  extensions  to  the  Multihost,  Multistage 
Vulnerability  Analysis  (MulVAL)  framework  to  support  DRDC  efforts  to  develop  a 
feasible  abstraction  in  the  area  of  defensive  posture  technology.  The  results 
presented  in  this  paper  demonstrate  that  the  MulVAL  model  is  extensible  and  can  be 
enhanced  to  include  additional  data  representation  and  analysis  features  to  tailor  the 
model  to  meet  the  need  of  the  DND  defence  community.  The  extensions  evaluated  in 
this  effort  have  been  shown  to  be  both  technically  valid  given  the  capabilities  of 
logic-based  programming  and  appropriate  given  the  current  model  data 
representations.  The  primary  extensions  researched  as  part  of  this  work  are: 
improved  representation  of  network  path  constructs  and  assignment  of  value  to  data 
assets  in  the  model.  This  paper  documents  a  substantial  degree  of  progress  in  the 
development  of  each  of  the  proposed  MulVAL  extensions. 


Resume 


Le  present  document  explique  en  detail  les  recherches  menees  sur  les  extensions  du 
cadre  d’analyse  de  vulnerabilite  multiutilisateur  et  echelonnee  (MulVAL)  a  Tappui 
des  demarches  de  RDDC  qui  visent  a  developper  une  abstraction  realisable  dans  le 
domaine  de  la  technologie  de  position  defensive.  Les  resultats  presentes  dans  ce 
document  demontrent  que  le  modele  MulVAL  est  extensible  et  qu’il  peut  etre  elargi 
pour  englober  d’autres  fonctions  de  representation  des  donnees  et  d’analyse  afm  de  le 
personnaliser  pour  qu’il  reponde  aux  besoins  de  la  collectivite  militaire  du  MDN.  Les 
extensions  evaluees  dans  le  cadre  de  Tinitiative  se  sont  revelees  valides  sur  le  plan 
technique  compte  tenu  des  capacites  de  la  programmation  a  base  logique  et 
appropriees  compte  tenu  du  modele  courant  de  representations  des  donnees.  Les 
principals  extensions  qui  ont  fait  l’objet  de  recherches  dans  le  cadre  du  projet  sont 
les  suivantes  :  representation  amelioree  des  constructions  de  chemins  de  reseau  et 
attribution  de  valeurs  aux  actifs  de  donnees  dans  le  modele.  Ce  document  fait  etat  du 
degre  eleve  de  progres  accompli  dans  le  developpement  de  chacune  des  extensions 
MulVAL  proposees. 
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Executive  summary 


In  2005,  Defence  Research  and  Development  Canada  (DRDC)  initiated  an  effort  to 
develop  a  feasible  abstraction  in  the  area  of  defensive  posture  technology.  A 
defensive  posture  technology  would  assess  the  defensive  state  of  a  network  based  on 
the  network  topology  and  configuration,  known  vulnerabilities,  and  operational 
requirements.  The  defensive  posture  abstraction  was  intended  to  provide  the 
necessary  framework  for  the  creation,  based  on  currently  available  technology,  of  a 
modelling  system  for  dynamic  risk  management  and  asset  protection. 

This  effort  resulted  in  the  creation  of  a  white  paper  entitled:  Dynamic  Asset- 
Protection  &  Risk  Management  Abstraction  Study.  Multihost,  multistage 
Vulnerability  Analysis  (MulVAL),  a  research  project  at  Princeton  University,  was 
identified  in  this  report  as  a  promising  area  of  research.  MulVAL  is  an  end-to-end 
framework  and  reasoning  system  that  conducts  complex  attack  vector  analysis  on  a 
network.  Extensions  to  MulVAL  that  would  be  beneficial  in  furthering  work  at 
DRDC  on  dynamic  network  defensive  posture  were  identified  in  the  white  paper. 

Further  investigation  revealed  several  other  projects  that  to  varying  degrees  meet  the 
requirements  of  a  defensive  posture  technology.  In  particular,  a  commercial  product 
called  Skybox  Security  and  an  Al-based  project  called  CycSecure  were  identified  as 
interesting  and  relatively  mature  projects,  which  deserve  closer  consideration  as 
candidates  for  a  defensive  posture  technology  to  meet  the  needs  of  the  defence 
community. 

The  research  in  this  paper  was  sponsored  to  examine  extensions  to  the  MulVAL  data 
model  and  to  provide  an  updated  critique  of  how  well  these  extensions  satisfy  the 
known  requirements  of  a  dynamic  asset  protection  solution.  A  critique  of  the  Skybox 
Security  and  CycSecure  solutions,  with  respect  to  the  requirements  of  dynamic  asset 
protection,  was  also  deemed  in  scope  for  this  effort. 

The  results  in  this  paper  demonstrate  that  the  MulVAL  model  is  extensible  and  can  be 
enhanced  to  include  additional  data  representation  and  analysis  features  to  tailor  the 
model  to  a  specific  problem  environment.  Specifically,  the  extensions  which  were 
proposed  in  the  Dynamic  Asset  Protection  &  Risk  Management  Abstraction  Study 
have  been  shown  to  be  both  technically  valid  given  the  capabilities  of  logic-based 
programming,  but  also  appropriate  given  the  current  MulVAL  model  data 
representations.  This  paper  documents  a  substantial  degree  of  progress  in  the 
development  of  each  of  the  proposed  MulVAL  extensions,  as  detailed  below. 

a.  The  network  MulVAL  extension  demonstrates  that  it  is  possible  to  extend  the 
simplistic  host  access  control  list,  currently  defined  in  the  existing  MulVAL 
model,  with  a  more  intuitive  approach  that  more  appropriately  reflects  real- 
network  design. 
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b.  The  asset  value  extension  demonstrates  that  it  is  possible  to  improve  existing 
predicates  to  include  additional  characteristics  for  improved  representation  of  the 
environment  being  modelled.  Given  the  ability  to  assign  a  valuation  to  data,  the 
tools  are  in  place  to  prioritize  the  attack  paths  which  are  established  though  a 
MulVAL  analysis. 

This  paper  proposes  that  additional  effort  to  refine  the  MulVAL  extensions  will  lead 
to  a  complete  set  of  valid  and  appropriate  enhancements  to  the  model.  Specifically,  it 
is  proposed  that  the  following  tasks  be  undertaken  to  progress  this  effort. 

a.  Further  enhance  the  attack  path  extension  to  determine  how  the  different  attack 
difficulty  assessments  /  valuation  methods  should  be  combined  to  determine  an 
overall  difficulty  value  for  the  attack  pattern; 

b.  Perform  more  data  instantiation  for  all  proposed  model  extensions  to  prove  the 
validation  of  the  approach  (in  the  spirit  of  the  work  that  was  done  for  the  network 
MulVAL  extension);  and 

c.  Assess  the  need  for  and  identify  any  additional  extensions. 


Bacic,  E.,  Henderson,  G.,  Froh,  M.  2006.  MulVAL  Extensions  for  Dynamic  Asset 
Protection.  DRDC  Ottawa  CR  2006-25 1  Defence  R&D  Canada  -  Ottawa. 
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Sommaire 


En  2005,  Recherche  et  developpement  pour  la  defense  Canada  (RDDC)  a  amorce  une 
initiative  en  vue  de  developper  une  abstraction  realisable  dans  le  domaine  de  la 
technologie  de  position  defensive.  Ce  type  de  technologie  evaluerait  l’etat  defensif 
d’un  reseau  en  fonction  de  la  topologie  et  de  la  configuration  de  ce  dernier,  des 
vulnerabilites  connues  et  des  besoins  operationnels.  L’abstraction  de  position 
defensive  visait  a  foumir  le  cadre  necessaire  a  1’  elaboration,  en  fonction  de  la 
technologie  actuellement  offerte,  d’un  systeme  de  modelisation  pour  gerer  les  risques 
et  proteger  les  biens  de  maniere  dynamique. 

L’ initiative  a  entraine  la  redaction  d’un  livre  blanc  intitule  :  Dynamic  Asset  Protection 
&  Risk  Management  Abstraction  Study.  Le  projet  d’analyse  des  vulnerabilites 
multiutilisateur  et  echelonnee  (MulVAL),  un  projet  de  recherche  de  l’Universite  de 
Princeton,  a  ete  designe  dans  le  rapport  comme  etant  un  domaine  de  recherche 
prometteur.  Le  modele  MulVAL  est  un  cadre  de  bout  en  bout  et  un  systeme  de 
raisonnement  qui  procede  a  des  analyses  complexes  de  vecteurs  d’attaque  dans  un 
reseau.  Les  extensions  du  modele  MulVAL  qui  permettraient  de  faire  avancer  a 
RDDC  les  travaux  sur  la  position  defensive  dynamique  dans  les  reseaux  ont  ete 
relevees  dans  le  livre  blanc. 

Des  etudes  plus  poussees  ont  revele  l’existence  de  plusieurs  autres  projets  qui,  a  des 
niveaux  differents,  satisfont  aux  exigences  en  matiere  de  technologie  de  position 
defensive.  Plus  particulierement,  un  produit  du  commerce  appele  Skybox  Security  et 
un  projet  d’lA  appele  CycSecure  ont  ete  designes  comme  etant  des  projets 
interessants  et  relativement  bien  developpes  dont  on  devrait  davantage  tenir  compte 
comme  acteurs  possibles  d’une  technologie  de  position  defensive  afm  de  repondre 
aux  besoins  de  la  collectivite  militaire. 

La  recherche  menee  aux  fins  ce  document  a  ete  organisee  pour  nous  permettre 
d’  examiner  les  extensions  au  modele  de  donnees  MulVAL  et  de  formuler  une  critique 
a  jour  en  ce  qui  a  trait  a  la  capacite  de  ces  extensions  a  satisfaire  aux  besoins  connus 
en  matiere  de  solution  de  protection  de  donnees  dynamique.  Une  critique  des 
solutions  Skybox  Security  et  CycSecure,  a  l’egard  des  exigences  en  matiere  de 
protection  de  biens  dynamique,  a  aussi  ete  consideree  comme  faisant  partie  du  cadre 
de  1 ’initiative. 

Les  resultats  contenus  dans  le  document  demontrent  que  le  modele  MulVAL  est 
extensible  et  qu’il  peut  etre  elargi  pour  englober  d’autres  fonctions  de  representation 
de  donnees  et  d’analyse  afm  de  l’adapter  a  un  environnement  de  probleme  specifique. 
Plus  particulierement,  les  extensions  proposees  dans  le  document  Dynamic  Asset 
Protection  &  Risk  Management  Abstraction  Study  se  sont  revelees  valides  sur  le  plan 
technique  compte  tenu  des  capacites  de  la  programmation  a  base  logique,  mais  aussi 
appropriees  compte  tenu  du  modele  MulVAL  courant  de  representations  de  donnees. 
Ce  document  fait  etat  du  degre  eleve  de  progres  accompli  dans  le  developpement  de 
chacune  des  extensions  MulVAL  proposees,  comme  on  l’explique  ci-dessous. 
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V 


a.  L’extension  de  reseau  MulVAL  montre  qu’il  est  possible  d’allonger  la  liste 
simplifiee  de  controle  d’acces  de  l’hote,  definie  dans  le  modele  MulVAL  existant, 
selon  une  approche  plus  intuitive  qui  correspond  de  fagon  plus  appropriee  a  la 
conception  «  reseau  reel  ». 

b.  L’extension  de  la  valeur  des  biens  demontre  qu’il  est  possible  de  developper  les 
predicats  existants  pour  englober  d’autres  particularites  afm  d’ameliorer  la 
representation  de  l’environnement  en  train  d’etre  modelise.  Com  me  il  est  possible 
d’attribuer  une  valeur  aux  donnees,  des  outils  permettent  d’etablir  l’ordre  de 
priorite  des  voies  d’attaque  etablies  grace  a  une  analyse  MulVAL. 

Dans  ce  document,  on  suggere  que  d’autres  demarches  visant  a  ameliorer  les 
extensions  MulVAL  meneront  a  un  eventail  complet  d’ameliorations  valables  et 
appropriees  au  modele.  Plus  particulierement,  on  propose  que  les  taches  ci-dessous 
soient  accomplies  pour  faire  avancer  le  dossier. 

a.  Ameliorer  davantage  1’ extension  de  voies  d’attaque  pour  determiner  comment  les 
differentes  evaluations/methodes  d’ evaluation  de  la  difficulte  des  attaques  doivent 
etre  regroupees  afm  d’etablir  un  indice  de  difficulte  global  pour  le  modele 
d’attaque. 

b.  Effectuer  davantage  d’instanciations  de  donnees  pour  les  extensions  de  modele 
proposees  afm  de  prouver  la  validation  de  l’approche  (dans  l’esprit  du  travail 
accompli  pour  l’extension  MulVAL  de  reseau). 

c.  Evaluer  les  besoins  en  matiere  d’ extensions  et  identifier  toutes  extensions 
supplementaires. 


Bacic,  E.,  Henderson,  G.,  Froh,  M.  2006.  MulVAL  Extensions  for  Dynamic  Asset 
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1.  Introduction 


1.1  Background 

In  2005,  Defence  Research  and  Development  Canada  (DRDC)  initiated  an  effort  to 
develop  a  feasible  abstraction  in  the  area  of  defensive  posture  technology  [1],  A 
defensive  posture  technology  would  assess  the  defensive  state  of  a  network  based  on 
the  network  topology  and  configuration,  known  vulnerabilities,  and  operational 
requirements.  Such  assessments  have  typically  been  done  via  a  static  threat  and  risk 
model;  however,  as  networks  and  operational  requirements  become  more  dynamic,  a 
correspondingly  dynamic  technology  for  network  monitoring  and  defensive 
assessment  is  needed.  Ideally,  this  defensive  posture  technology  would  monitor 
changes  to  the  network  configuration,  be  aware  of  newly  discovered  vulnerabilities, 
permit  asset  value  to  be  assigned  dynamically  based  on  operational  requirements,  and 
identify  the  possible  means  by  which  an  attacker  could  compromise  the  network’s 
security  policy  or  undermine  the  operations  which  the  network  supports. 

The  defensive  posture  abstraction  was  intended  to  provide  the  necessary  framework 
for  the  creation,  based  on  currently  available  technology,  of  a  modelling  system  for 
dynamic  risk  management  and  asset  protection.  It  was  determined  that  a  new 
approach  was  needed  which  could  model  threat  propagation  in  the  network  via  multi¬ 
stage  attacks. 

This  effort  resulted  in  the  creation  of  a  white  paper  entitled:  Dynamic  Asset 
Protection  &  Risk  Management  Abstraction  Study  [2],  A  research  project  at 
Princeton  University  called  MulVAL  was  identified  in  this  report  as  a  promising  area 
of  research  [3],  [4],  [5],  and  [6].  Multihost,  multistage  Vulnerability  Analysis 
(MulVAL)  is  an  end-to-end  framework  and  reasoning  system  that  conducts  complex 
attack  vector  analysis  on  a  network.  The  output  is  a  set  of  attack  vectors  specific  to 
the  network  in  question.  Extensions  to  MulVAL  that  would  be  beneficial  in 
furthering  work  at  DRDC  on  dynamic  network  defensive  posture  were  identified  in 
[2]- 

Further  investigation  revealed  several  other  projects  that  to  varying  degrees  meet  the 
requirements  of  a  defensive  posture  technology.  In  particular,  a  commercial  product 
called  Skybox  Security  and  an  Al-based  project  called  Cyc Secure  were  identified  as 
interesting  and  relatively  mature  projects,  which  deserve  closer  consideration  as 
candidates  for  a  defensive  posture  technology  to  meet  the  needs  of  DND. 

1.2  Scope 

The  proposed  research  will  result  in  new  MulVAL  data  model  extensions  in  Datalog, 
an  updated  critique  of  how  well  MulVAL  plus  the  extensions  satisfies  the 
requirements  of  dynamic  asset  protection,  and  a  summary  of  areas  requiring  future 
research. 
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A  secondary  objective  is  to  critique  Skybox  Security  and  CycSecure  with  respect  to 
the  requirements  of  dynamic  asset  protection. 


1.3  Report  Structure 

Section  2  contains  the  conclusions  from  the  critique  of  the  alternative  DAP  models: 
Skybox  and  CycSecure.  The  full  critique  is  contained  in  Annex  A. 

Section  3  contains  the  MulVAL  model  extensions  in  each  of  the  following  areas: 
Networking,  Asset  Sensitivity,  and  Attack  Paths.  For  each  of  these  extensions,  the 
sub-section  contains: 

a.  The  Objective  of  the  extension; 

b.  The  Extension  definition  in  Datalog  syntax; 

c.  The  proposed  source  of  any  Datalog  facts  needed  for  the  extension; 

d.  A  discussion  on  the  design  rationale  behind  the  extension  definition;  and 

e.  A  critique  of  how  well  the  defined  extension  meets  the  objective. 

Section  4  contains  observations  on  the  general  MulVAL  model.  These  observations 
were  made  while  working  with  the  existing  MulVAL  code. 

Section  5  contains  observations  on  the  information  found  within  the  National 
Vulnerability  Database  (NVD),  a  prime  source  for  MulVAL  related  facts  on 
vulnerabilities.  The  observations  include  a  brief  analysis  of  the  Common 
Vulnerability  Scoring  System  (CVSS),  which  is  included  for  most  of  the  listed 
vulnerabilities. 

Section  6  contains  conclusions  of  the  MulVAL  extension  work,  as  well  as  identifying 
topics  for  future  research. 

Section  7  contains  the  references  used  within  this  report. 

Annex  A  contains  the  full  critique  of  MulVAL,  Skybox,  and  CycSecure  against  the 
DAP  requirements. 

Annex  B  contains  detailed  listings  of  the  MulVAL  Network  Extension  including 
some  modelling  outputs. 

Annex  C  contains  detailed  listings  of  the  MulVAL  Asset  Extension. 

Annex  D  contains  detailed  listings  of  the  MulVAL  Attack  Weight  Extension. 
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2.  Alternative  Model  Critique 

Prior  to  working  on  the  MulVAL  model  extensions,  two  other  projects  that  appeared 

to  meet  the  requirements  of  a  defensive  posture  technology  were  examined: 

a.  A  commercial  product  called  Skybox  Security  [7],  [8],  [9],  [10],  [11],  and  [12]; 
and 

b.  An  Artificial-Intelligence  (AI)  based  project  called  CycSecure  [13],  [14],  and 
[15]. 

An  overall  examination  of  these  two  models,  and  MulVAL,  was  performed.  The 

results  of  the  analysis  are  contained  in  Annex  A  -  MulVAL,  Skybox,  and  CycSecure 

Critique.  The  presentation  of  the  analysis  is  done  in  two  large  tables: 

a.  Annex  A  -  Table  1  -  Tool  Set  Architecture  provides  a  comparative  view  of  all 
three  tools  with  regard  to:  information  available,  network  model  collection, 
vulnerability  knowledge,  information  analysis,  information  presentation, 
performance  of  information  collection,  performance  of  information  analysis,  and 
scalability;  and 

b.  Annex  A  -  Table  2  -  Critique  of  Toolsets  in  Providing  DAP  Abstraction 
Requirements.  This  table  has  identical  rows  to  the  MulVAL  critique  in  [2].  The 
table  has  three  columns  for  each  of  MulVAL,  Skybox,  and  CycSecure.  The 
MulVAL  critique  is  largely  that  provided  in  [2]  with  some  minor  updates.  The 
Skybox  and  CycSecure  critiques  are  new. 

The  following  are  conclusions  regarding  the  three  tool  sets  available  to  implement 

DAP: 

a.  MulVAL  and  CycSecure  provide  the  most  comprehensive  attack  path  modelling 
since  they  both  include  host-based  scanners.  Of  the  two  CycSecure  may  provide 
a  more  comprehensive  attack  path  model  since  its  ontology  appears  more  refined; 
however,  this  hypothesis  is  not  supported  by  the  CycSecure  references  [13],  [14], 
and  [15].  In  order  to  model  most  real-world  attack  paths,  a  tool  needs  to  model 
internal  host  privilege  escalation  vulnerabilities  that  are  tied  to  user  accounts  and 
file  access  permissions.  Skybox  does  not  include  this  depth  of  internal  system 
information  collection.  Therefore,  attack  path  reasoning  can  only  be  a  subset  of 
the  attack  paths  found  using  MulVAL  or  CycSecure  reasoning. 

b.  MulVAL  is  much  better  at  detecting  accidental  mis-configurations  since  it  has  an 
inside  view  of  the  host  and  uses  Open  Vulnerability  and  Assessment  Language 
(OVAL),  which  defines  typical  configuration  errors.  Skybox  can  only  base  their 
analysis  on  what  they  see  from  the  outside  and  would  likely  miss  many 
configuration  issues.  CycSecure  should  be  capable  of  detecting  mis- 
configurations,  but  this  is  cited  as  future  work  [15]. 
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c.  Skybox  is  a  “glue”  product  that  will  correlate  and  analyse  other  information 
sources  in  a  more  meaningful  manner  than  the  originals.  The  degree  of  the 
product’s  analysis  capabilities  is  unclear  but  likely  contained  in  the  View 
Dictionary.  Depending  on  how  the  analysis  and  View  Dictionary  are 
implemented,  the  product  may  have  a  brittle  architecture,  which  requires  constant 
tweaking/updating  from  the  company  to  accommodate  new  vulnerabilities  and 
how  they  relate  to  existing  ones.  The  fact  that  Skybox  presents  other  product 
information  makes  it  a  likely  target  for  large  players  in  the  vulnerability  scanning 
market  to  easily  incorporate  Skybox  functionality.  This  is  a  risky  business  model. 
Skybox  needs  to  provide  significant  value-add  in  analyzing  correlated  data  from 
these  various  information  sources  in  order  to  survive;  but  this  doesn’t  appear  to  be 
a  strong  capability  yet. 

d.  Cyc  Secure  is  a  proof  of  concept  to  prove  that  Cyc  is  of  use  in  real-world 
problems.  CycSecure  was  trialled  for  six  months  in  the  US  STRATCOM  CERT, 
but  it  is  unclear  how  extensively  its  Sentinels  were  deployed.  CycSecure  is  not 
yet  a  viable  product  since  its  web  pages  do  not  provide  any  marketing,  sales, 
technical,  support,  or  contact  information! 

e.  We  only  have  hard  performance  and  scalability  data  for  MulVAL.  CycSecure 
appears  to  be  scalable  and  reason  on  attack  plans  in  a  reasonable  timeframe. 
Skybox  has  no  indications  of  scalability.  To  handle  really  large  networks,  we  will 
likely  have  to  use  abstraction  techniques  to  decompose  large  networks  into 
smaller  elements  for  sub-analysis.  The  Cyc  knowledge  base  and  reasoning 
engine  already  have  techniques  for  handling  this.  MulVAL  could  likely  be 
extended  to  include  these  types  of  techniques.  It  is  unclear  whether  Skybox  can 
apply  abstractions  in  its  analysis  ability. 

f.  All  of  the  tools  essentially  provide  a  snapshot  in  time  analysis.  All  can  be 
configured  for  periodic  information  collection  and  analysis.  None  of  the  products 
are  geared  towards  truly  dynamic  environments,  such  as  tactical  military 
networks,  which  tend  to  favour  a  DAP-O-Matic1  approach.  None  of  the  products 
incorporates  feedback  into  the  model  to  refine  its  scanning/analysis  methods  (for 
example,  altering  information  collection  techniques  based  on  previous  scan  data). 

After  this  tool  analysis,  MulVAL  is  still  a  good  candidate  for  implementing  DAP. 

Therefore,  the  remainder  of  this  report  provides  the  modelling  extensions  performed 

in  Datalog  according  to  the  existing  MulVAL  data  model. 


1  The  term  DAP-O-Matic  was  adopted  in  [2],  although  this  term  has  been  changed  to  Mole-O-Matic. 
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MulVAL  Extensions 


The  approach  taken  in  developing  MulVAL  extensions  was  to  follow  the  following 
principle:  minimize  changes  to  the  existing  MulVAL  model  if  possible.  This  reduces 
the  work  in  folding  these  extensions  back  into  the  MulVAL  source 

The  MulVAL  extensions  identified  in  [2]  were  reviewed  and  a  priority  of  extension 
implementation  was  developed  based  on: 

a.  DAP  requirements; 

b.  Preliminary  design  discussion;  and 

c.  Likelihood  of  successful  implementation  in  a  given  timeframe. 

The  priority  of  MulVAL  extension  implementation  is  given  in  Table  1  below.  A  sub¬ 
section  is  presented  for  each  of  the  three  MulVAL  model  extensions  examined. 


Table  1.  MulVAL  Extension  Implementation  Priority  (Highest  to  Lowest) 


DAP  REQUIREMENT 

DESIGN  DISCUSSION 

LIKELIHOOD  OF 

IMPLEMENTATION 

IMPLEMENTATION 

STATUS 

Networking  Element 

•  Describe  computer 

•  More  closely  matches 

•  High  for  following 

•  Done 

network  resources  as 

actual  network 

reasons: 

interdependent 

elements. 

configurations. 

•  The  authors  have 

•  See  Section  3.2 

•  Explicitly  models 

previous  work 

•  Describe  security 

network  safeguards 

experience  in  the  area. 

safeguards  as  attributes 

(firewall/router/VPN)  as 

of  computer  network 

hosts  that  can  have 

•  Easy  extension  due  to 

resources. 

vulnerabilities  and  be 

understanding  of  what 

part  of  attack  paths. 

needs  to  be  modelled. 

•  Map  threat  events  onto 

computer  network 

•  Many  possible 

resources  with 

automated  info  sources 

vulnerability  safeguard 
attributes. 

(SNMP  managers, 
firewall  outputs). 

•  Generally  decompose  a 
large  network  into 

•  Easy  MulVAL  integration 
since  can  derive  existing 

smaller  networks. 

hacl/4  rules. 
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Table  1.  MulVAL  Extension  Implementation  Priority  (Highest  to  Lowest) 


DAP  REQUIREMENT 


Asset  Value 

•  Map  mission-required  IT 
services  onto  computer 
network  resources. 

•  Combine  computer 
network  resources  into 
IT  service  offerings  that 
support  a  required 
confidentiality,  integrity, 
and  availability  Quality  of 
Service  (QoS). 

.  Ref  [1]  added 
Accountability. 

•  Relate  threat  events  to 
safeguard  effectiveness 
and  vulnerabilities. 

Safeguard  Model 

•  Describe  security 
safeguards  as  attributes 
of  computer  network 
resources. 

•  Extension  to  model  *NIX 
execute  privilege  (can 
attacker  execute 
vulnerable  program?). 

•  Extension  to  model  *NIX 
user/group/world 
privileges. 

•  Extension  to  model  *NIX 
and/or  Windows  ACLs. 

•  Map  threat  events  onto 
computer  network 
resources  with 
vulnerability  and 
safeguard  attributes. 

•  Relate  threat  events  to 
safeguard  effectiveness 
and  vulnerabilities. 


DESIGN  DISCUSSION 


•  Source  of  asset  value 
will  have  to  be  manually 
created. 

•  MulVAL  currently  doesn't 
handle  service  modelling 
to  the  extent  we  need  it 
to:  no  binding  to  data. 

•  Consider  an  asset 
impact  extension  to 
show  more  granularity 
on  consequences. 

•  Consider  extending  to 
CVSS  C/I/A  model 
(richer  than  currently 
used  NVD  model). 


•  Princeton  has  already 
modelled  Windows 
environment  including 
ACLs  [6]  (and  much 
more).  Is  it  extendable 
into  their  USENIX  paper 
MulVAL  model? 

•  Currently  only  model 
preventative  safeguards. 
Can  we  extend  to 
include  detection, 
containment  and 
recovery  safeguards? 

•  Need  to  model  network 
safeguards  explicitly 
(see  Section  3.2). 

•  Need  to  model 
safeguard  effectiveness. 
Current  model  has 
binary  effectiveness,  or 
lack  of  vulnerability 
implies  perfect 
safeguard. 


LIKELIHOOD  OF 
IMPLEMENTATION 


•  Moderate  for  following 
reasons: 

•  Good  understanding  of 
Confidentiality 
requirement. 

•  Bad  understanding  of 
Integrity  requirement. 

•  Moderate  understanding 
of  Availability 
requirement. 

•  Bad  understanding  of 
Accountability 
requirement. 


•  Implementing  non-binary 
Attack  Weights  likely  a 
big  impact  on  existing 
model  and  attack  tree 
visualization. 

•  Prolog  truth  output 
(true/false)  to  queries 
now  a  probability 
function  based  on  attack 
path  safeguard 
effectiveness. 

•  Consider  CVSS  as  an 
available  online  data 
source  for  vulnerability 
difficulty,  or  safeguard 
effectiveness.  This 
information  can  be 
queried  through  an 
automated  process, 
without  the  intervention 
from  an  analyst. 

•  Modelling  other  than 
preventative  safeguards 
is  embryonic. 


IMPLEMENTATION 

STATUS 


•  Started 

•  See  Section  3.3 


•  Network  safeguard 
modelling  done,  see 
Section  3.2 

•  Started  examining 
modelling  attack  weights 
in  a  non-binary  manner. 
See  Section  3.3.5 


3.1  General  Extension  Approach 

In  order  to  deal  with  information  dynamically  we  need  to  consider  the  following: 
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a.  Asset  value; 

b.  Attack  path; 

c.  Value  as  a  function  of  time;  and 

d.  Dynamism  of  attacks. 

There  are  a  number  of  ways  of  proceeding,  but  the  most  logical  way  would  be  to 
leverage  the  power  of  Prolog  and  predicates.  This  can  be  achieved  by  actually  storing 
all  information  relating  to  a  specific  predicate  within  the  predicate  itself. 

This  means  that  we  define  asset  value,  asset  classification,  etc.  as  predicates: 

assetValue (Asset,  Value) 

or  possibly  as  a  set  of  values: 

assetValue (Asset,  ConfidentialityValue,  IntegrityValue, 
AvailabilityValue) . 

Similarly,  we  define  each  asset  as  having  a  specific  classification: 

assetClassification (Asset,  Classification,  Caveat) 

so  that  we  can  state  predicates  such  as: 

assetClassification (fileXYZ,  secret,  ceo) . 

This  would  then  allow  us  to  quickly  determine  which  assets  are  of  a  given 
classification: 

assetClassification (AssetList,  secret,  _) 

or  we  can  find  what  a  specific  asset  has  as  its  classification  and  caveat: 

assetClassification (fileXYZ,  Classification,  Caveat) 

or  we  can  find  all  assets  with  CEO: 

assetClassification (AssetList,  _,  ceo). 

The  flexibility  this  offers  us  is  that  we  can  use  this  in  a  codified  manner  within  the 
various  predicates  that  determine  attack  paths.  Based  on  other  external  inputs  we  can 
modify  the  behaviour  of  the  system  dynamically  since  the  predicates  can  be  restated 
as  required. 

This  ability  to  change  the  associations  between  a  given  asset  and  its  associated  values 
is  crucial  to  allowing  for  temporal  attack  path  determination.  For  example,  should  an 
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asset  be  deemed  no  longer  classified,  it  can  be  downgraded  by  means  of  a  simple 
function  which  will  perform  the  following  actions 

a.  Take  an  asset  as  an  argument; 

b.  Store  the  current  classification; 

c.  Retract  the  asset;  and 

d.  Add  the  asset  to  the  database  with  a  classification  level  one  lower  than  its 
previous  value. 

For  example,  if  we  are  only  interested  in  attacks  against  Secret  assets,  then  the  attack 
paths  to  the  provided  asset  immediately  can  be  eliminated  from  the  search.  This 
dynamism  is  something  that  has  historically  been  very  difficult  to  do. 

It  is  possible  to  create  biases  in  the  attack  paths  by  simply  adding  in  a  few  predicates 
that  leverage  classification  and  asset  value.  In  fact,  it  could  be  argued  that  asset  value 
should  be  tightly  tied  to  classification. 

It  would  appear  that  the  best  option,  therefore,  is  to  create  more  predicates.  This 
appears  to  be  generally  true  for  everything  that  must  be  extended  within  the  MulVAL 
model.  The  reason  for  this  view  is  that  it  becomes  possible  to  query  the  rules 
efficiently  to  determine,  for  example,  all  assets  of  a  particular  classification  or  of  a 
particular  value.  The  other  reason  to  prefer  predicate  representation  is  that  it  allows 
the  model  to  remain  simple  rather  than  creating  the  complexity  of  passing  vectors  and 
variables.  Leveraging  the  power  of  Prolog  actually  lessens  the  amount  of  custom 
coding  that  is  required. 

Thus,  instead  of  extending  a  given  predicate  with  more  variables  we  amend  the  actual 
code  to  handle  new  predicates  such  as: 

assetValue (Asset,  Confidentiality,  Integrity,  Availability, 
bias) 

assetClass (Asset,  Classification) 

This  allows  the  definition  of  each  asset  uniquely  as  a  name-value  pair  within  Datalog: 

assetClass (someAsset,  secret) 
assetClass (someOtherAsset,  secret) 
assetClass (yetAnother,  topsecret) 

This  allows  any  routine  simply  do  the  following  to  get  back  every  asset  that  is 
classified  Secret,  namely  someAsset  and  someOtherAsset. 

assetClass (Assets,  secret) 

It  also  means  that  predicates  focus  on  the  assets  as  opposed  to  trying  to  pass 
parameters  around  unnecessarily. 

In  this  way,  Prolog  handles  all  the  actual  data  storage  and  retrieval  and  manipulation. 
Also,  if  an  asset's  classification  changes,  for  example,  from  Secret  to  Unclassified,  it 
only  requires  the  following: 
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assetClass (yetAnother,  unclassified) 


This  representation  is  simple  and  intuitive  to  the  reader.  Also,  manipulating  the 
predicates  is  straightforward  as  with  the  function  to  perform  a  downgrade,  for 
example,  to  declassify  an  existing  asset: 

makeUnclassif ied (Asset) 

Old  =  . . [Asset,  _] ,  retract  (Old) , 

New  =  . . [Asset,  unclassified] ,  assert  (New) . 

By  performing  dynamic  downgrades,  or  by  inserting  new  clauses  into  Prolog's 
database,  it  is  possible  to  alter  dynamically  the  behaviour  of  MulVAL.  It  is 
significant  to  note  that  Datalog  permits  dynamic  manipulation  of  its  clause  database.2 

For  the  ranking  of  attack  trees,  an  association  would  need  to  be  created  between  the 
asset  and  the  device  upon  which  the  asset  resides.  In  order  to  examine  paths  that  have 
high  value  assets,  a  bias  in  MulVAL  would  need  to  be  established  to  examine  paths  to 
assets  of  a  particular  value  before  others.  This  should  be  easily  done  by  having  the 
appropriate  functions  request: 

assetValue  (Asset,  secret) 

to  get  a  full  list  of  all  secret  assets  and  then: 

assetResides  (Asset,  Machine) 

In  other  words,  the  machine  classification  is  a  function  of  the  assets  that  reside  on  it. 
The  predicate  to  list  all  machines  with  a  specified  type  of  data  is: 

machineClassification (Classification,  Machine) 
assetValue (Asset,  Classification,  )  , 
assetResides (Asset,  Machine)  . 

Obtaining  the  list  of  machines  that  are  classified  as  secret  would  be  done  through  a 
call  similar  to: 

machineClassification (secret.  Machine) . 

Alternatively,  obtaining  the  classification  of  a  specific  machine  (e.g.  “target  system”) 
would  be  done  through  a  call  similar  to 

machineClassification (Classification,  targetsystem) . 


2  Specifically,  the  Datalog  implementation  currently  used  by  the  MulVAL  implementation  (XSB) 
supports  this  dynamic  manipulation  of  the  clause  database. 
http://xsb.sourceforge.net/manuall/nodel03.html 
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3.2  Network  MulVAL  Extension 


3.2.1  Objective 

The  objective  of  this  MulVAL  extension  is  to  derive  had/ 4  Datalog  rules  in 
a  more  intuitive  manner  that  reflects  real-network  design  principles.  The 
extension  should  be  capable  of  modelling  the  network  elements  shown  in 
Figure  1: 

a.  Flosts  belonging  to  a  subnet; 

b.  Multi-homed  hosts  which  belong  to  two,  or  more,  sub-nets; 

c.  Routers  and  firewalls  are  a  special  case  of  multi-homed  hosts  which  also 
perform  a  routing  function  between  sub-nets; 

d.  Modelling  of  simple  routes  of  two  subnets  connected  by  a  single  router; 
and 

e.  Modelling  of  transitive  routes  of  two  subnets  connected  by  two,  or  more, 
routers,  and  one,  or  more,  transiting  sub-nets. 


Figure  1.  Complex  Network  Modelling 

3.2.2  Extension  Definition 

The  complete  extension  definition  is  contained  in  Annex  B  -  MulVAL 
Network  Extension.  The  key  extension  components  are  described  here. 
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Complex  networks  can  be  modelled  using  two  primitive  Datalog  predicates: 
hosts  are  attached  to  a  network: 

hostNet  (Host,  Net). 

routeEntry (Router ,  Initnet,  Targetnet,  Protocol,  Port). 

The  above  primitives  define  which  subnets  hosts  are  attached  to  and  defined 
routes  between  subnets  at  routing  points. 

From  these  two  primitive  Datalog  elements  the  following  two  derived 
Datalog  primitives  are  defined: 

route  (InitNet,  TargetNet,  Protocol,  Port). 

had ( InitHost,  TargetHost,  Protocol,  Port). 

The  first  derived  primitive  is  looking  for  valid  routes  amongst  all  routers. 
The  second  derives  haci/4  rules  based  on  hostNet/2  and  route/4.  The 
derivation  of  these  two  primitives  is  defined  using  the  following  four 
interaction_rules,  two  to  derive  route/ 4,  and  two  to  derive  had/ 4  rules.3 

/******  Route  Section  *******/ 
interaction_rule ( 

(route  (InitNet,  TargetNet,  Protocol,  Port) 
routeEntry (Router ,  InitNet,  TargetNet,  Protocol,  Port), 
hostNet  (Router, InitNet) , 
hostNet (Router, TargetNet)  )  , 

'Direct  route  between  subnets  through  an  intermediate 
router ' ) . 

interaction_rule ( 

(route  (InitNet,  TargetNet,  Protocol,  Port) 
route (InitNet,  TransitNet,  Protocol,  Port), 
route  (TransitNet,  TargetNet,  Protocol,  Port)), 
'Transitive  routing  through  an  intermediate  network'). 

/******  HACL  Section  *******/ 

interaction_rule ( 

(had ( InitHost,  TargetHost,  Protocol,  Port) 
hostNet ( InitHost,  InitNet) , 
hostNet  (TargetHost,  TargetNet) , 

InitNet  \=  TargetNet, 

route  (InitNet,  TargetNet,  Protocol,  Port)), 

'Hosts  can  only  communicate  between  networks  through  a 
valid  route . ' ) . 

interaction_rule ( 


3  Commonly,  port  information  from  network  devices  (e.g.  firewalls)  is  presented  as  ranges.  A  useful 
expansion  of  the  work  presented  in  this  paper  would  be  to  determine  a  method  by  which  port  ranges 
can  be  expressed  within  the  constraints  of  the  logic-based  program  syntax. 
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(had  (InitHost,  TargetHost,  _,  _) 
hostNet  ( InitHost,  CommonNet) , 
hostNet (TargetHost,  CommonNet)), 

'Hosts  on  same  network  have  no  communication 
restrictions. ') . 

3.2.3  Data  Source 

With  the  network  extension  defined  above,  a  data  source  needs  to  be 
identified  for  the  identified  primitive  Datalog  predicates,  namely: 

a.  hostNet/2  -  this  information  can  be  derived  from  a  number  of  automated 
sources  including:  host-based  scanners  such  as  MulVAL’s  OVAL 
scanner,  DNS  records,  DHCP  leases,  ARP  listening  or  ping  sweeps  of  a 
network;  and 

b.  routeEntry/  5 — the  most  reliable  source  of  information  can  be  derived 
from  routers  and  firewalls,  or  from  any  management  system  for  these 
devices.  Examples  might  include  Simple  Network  Management  Protocol 
(SNMP)  consoles,  proprietary  device  management  consoles,  and 
processes  running  on  the  devices  themselves.  Less  reliable  routing 
information  can  be  derived  from  network  mapping  tools  such  as  nmap. 

3.2.4  Design  Rationale 

The  existing  MulVAL  had/ 4  network  model  is  limited  in  the  complexity  of 
networks  that  it  can  model.  It  is  particularly  difficult  to  use  wild  cards  in 
defining  had/ 4  primitives  since  these  often  won’t  reflect  actual  network 
connectivity.  This  means  one  would  typically  have  to  define  individual 
had/ 4  primitives  for  all  host-to-host  network  connectivity,  which  is  a 
tedious  exercise. 

The  primitive  Datalog  predicate  design  ensures  that  data  can  be  automatically 
derived  from  several  potential  sources. 

The  primitive  and  derived  Datalog  predicates  are  much  more  intuitive  and 
model  real  network  designs  than  had/ 4  rules  do. 

Since  routers  and  firewalls  are  special  cases  of  multi-homed  hosts,  they  can 
also  have  inherent  vulnerabilities  and  network  services  running  on  them. 

This  explicitly  models  filtering  routers  and  firewalls  as  safeguards. 

Typical  router  and  firewall  configurations  can  be  defined  including  situations 
with  multiple  interfaces.  For  example,  a  single  firewall  can  have  Internet,  de¬ 
militarized  zone  (DMZ),  and  Intranet  interfaces  with  differing  routeEntry/ 5 
definitions  that  reflect  a  real  policy. 

The  routeEntry/ 5  primitives  define  individual  one-way  data  flow  policies. 
This  method  of  representing  network  connectivity  in  terms  of  source, 
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destination,  protocol,  and  port  and  using  this  construct  to  define  and  drive 
valid  path  routes  is  very  much  in  accordance  with  existing  firewall  practices, 
most  notably,  the  iptables4  packet  filtering  framework.  While  iptables  allows 
the  definition  of  policy  for  inbound,  forwarding  and  output  packet  flow, 
MulVAL,  and  the  proposed  extension,  takes  a  purely  outbound  view  of  the 
network  path.  That  is,  the  had/ 4  rules  determine  what  is  accessible  from  a 
specific  source  to  a  specific  destination. 

In  the  first  had/4  interaction  rule,  initNet  \=  TargetNet  was  added  for 
efficiency.  In  the  case  where  InitHost  and  TargetHost  are  on  the  same  subnet 
(the  case  handled  by  the  second  hacl/4  rule)  this  condition  makes  evaluation 
much  faster. 

3.2.5  Extension  Critique 

The  network  extension  successfully  derived  had/ 4  Datalog  primitives  when 
integrated  with  MulVAL.  This  provided  a  simple  and  elegant  manner  in 
which  the  extension  was  integrated  back  into  the  MulVAL  model.  Tests  on 
the  network  shown  in  Figure  1  show  that  the  network  could  be  defined  using 
14  hostNet/2  and  6  routeEntry/5  network  extension  primitives  while  it 
derived  131  had/4  primitives  (the  source  Datalog  facts  and  derived  had/4 
primitives  are  contained  in  Annex  B).  A  review  of  the  derived  had/ 4 
primitives  in  Annex  B  shows  that  routes  to  all  of  the  interfaces  of  multi¬ 
homed  systems  are  found.  An  example  of  finding  routes  to  different 
interfaces  of  multi-homed  systems  is: 

a.  had  (al,  multi,  _)  on  the  netA  interface  of  multi;  and 

b.  had  (al ,  multi,  tcp,  8  0 )  on  the  netB  interface  of  multi,  using  the 
route  through  router AB. 

One  concern  with  the  currently  defined  extension  is  that  had/ 4  rules  that 
refer  to  local  machine  do  not  distinguish  between  interfaces  on  that  system: 

had  (router,  router,  _,  _) 

In  this  example,  there  are  valid  paths  between  all  interfaces  on  the  router,  a 
loss  of  granularity  which  may  expose  more  paths  that  actually  exist.  An 
amendment  to  the  extension  would  include  interface  to  the  had/ 4  rule,  using 
a  primitive  declaration  which  would  only  have  significance  for  multi-homed 
systems. 

In  complex  networks,  the  savings  in  data  input  are  substantial  and  eliminate 
any  potential  for  logic  errors  in  manually  deriving  had/ 4  primitives  assumed 
in  the  existing  MulVAL  model. 


4  http://www.netfilter.org/ 
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The  network  extension  as  defined  must  have  consistent  hostNet/2  and 
routeEntry/5  primitives  defined  to  properly  map  routers  and  firewalls.  That 
is,  the  data  source  must  ensure  that  a  hostNet/2  primitive  is  defined  for  each 
router/firewall  subnet  interface  to  ensure  that  route/ 4  is  properly  derived 
from  routeEntry/5.  We  could  loosen  the  first  route/4  definition  by 
removing  the  hostNet/2  requirements  of  the  routers.  However,  one  would 
not  derive  had/ 4  rules  for  attack  paths  to  the  routers  themselves,  which  is 
limiting.  A  more  elegant  design  would  remove  the  requirement  for  explicitly 
defining  hostNet/2  primitives  for  any  device  with  a  routeEntry/5  and  the 
model  would  derive  these. 

The  network  extension  as  defined  doesn't  handle  port  forwarding  at  a  firewall. 
The  port  forwarding  could  be  handled  by  extending  the  routeEntry/5  to: 

routeEntry ( initNet,  targetNet,  targetHost,  protocol,  port) 

where  typical  routing  entries  would  have  "Any"  under  targetHost.  This 
would  handle  the  port  forwarding  but  one  would  have  to  be  careful  in 
defining  the  rules  (for  example,  don't  define  two  port  80  forwards). 

The  network  extension  as  defined  doesn't  handle  Network  Address 
Translation  Port  (NATP),  or  port  redirection.  This  might  also  be  handled  by  a 
similar  extension  to: 


routeEntry ( initNet,  incomingPort,  targetNet,  targetHost, 
protocol,  outgoingPort) 

where  incomingPort  =  outgoingPort  in  most  cases  (for  example,  80  and  80 
for  http).  With  this  rule  one  could  define  incoming  port  80  becomes  outgoing 
port  8080.  Our  discussion  to  date  is  that  this  extension  might  be 
overcomplicating  the  model  right  now  for  a  feature  that  may  not  be  heavily 
used  in  an  Enteiprise  environment  (from  our  estimation). 

The  network  extension  as  defined  doesn't  handle  source  IP  blocking,  which  is 
typical  firewall  functionality.  We  started  down  a  similar  routeEntry/5 
extension  of  adding  an  "initHost"  parameter  but  quickly  decided  this  was 
flawed  thinking.  It  is  very  difficult  to  build  blocking  rules  with  inclusive  rule 
types.  For  example,  if  one  host  were  blocked  from  any  outgoing  connections, 
one  would  have  to  explicitly  define  allowed  rules  for  all  remaining  hosts  on 
the  subnet  -  clearly  not  a  good  model  design.  We  think  some  form  of 
notAi lowed  parameter  similar  to  routeEntry/5  and  use  with  negation  to 
build  had/ 4  rules.  We  have  not  explored  this  any  further. 

The  network  extension  as  defined  implies  a  change  to 
networkServiceinfo/5  to  include  a  _net  parameter  that  the  service  is 
listening  on.  Without  defining  this  extension  to  networkServiceinfo/5,  the 
MulVAL  logic  will  assume  that  any  service  is  listening  on  all  interfaces. 
Although  this  may  be  the  default  configuration  of  many  services,  it  becomes 
particularly  important  at  important  firewall  boundaries  where  firewall 
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management  services  would  only  be  listening  on  inner,  trusted  subnets.  This 
is  evident  in  the  Annex  B  listing  where  it  appears  that  multiple  had/ 4 
primitives  are  derived  between  the  same  initiator  and  target  systems.  In  these 
cases,  the  listing  explicitly  shows  routes  to  two  different  interfaces  on  the 
target  system.  Therefore,  consideration  should  be  given  to  extend  the  had/ 4 
primitive  to  also  show  the  target  interface.  An  example  of  these  two  explicit 
routes  from  Annex  B  are: 

a.  had  (at, multi,  )  on  the  netA  interface  of  multi;  and 

b.  had  (ai , multi,  tcp,  80)  on  the  netB  interface  of  multi,  routed  through 
routerAB. 

3.3  Asset  MulVAL  Extension 

3.3.1  Objective 

The  objective  of  a  MulVAL  Asset  Extension  is  to  provide  basic  tracking  of 
asset  sensitivity.  The  current  MulVAL  model  [4]  does  not  track  asset 
sensitivity  at  all,  but  can  define  authorized  policies  of  who  can  access  what 
data.  It  is  notable  that  the  USENIX  paper  where  the  MulVAL  model  was 
presented  included  a  statement  to  indicate  that  the  omission  of  asset  value 
from  the  model  was  a  function  of  the  lack  of  source  data,  not  inherent 
limitation  of  the  model  itself. 

"Currently  we  do  not  have  exploit  rules  for  vulnerabilities  whose  exploit  consequence 
is  confidentiality  loss  or  integrity  loss.  The  ICAT  database  does  not  provide  precise 
information  as  to  what  confidential  information  may  be  leaked  to  an  attacker  and 
what  information  on  the  system  may  be  modified  by  an  attacker. " 

Tracking  asset  sensitivity  will  allow  sorting  of  attack  trees  derived  by 
MulVAL  to  be  sorted  in  an  order  of  criticality,  a  feature  that  is  more  crucial 
to  defending  networks.  An  ordered  list  of  attack  paths  against  an 
organization’s  most  sensitive  assets  is  needed. 

An  initial  point  is  to  establish  the  categories  for  asset  valuation  that  will  be 
targeted  by  this  extension.  Lrom  an  asset  perspective  there  are  two  main 
categories:  data  and  processes.  Each  of  these  categories  can  be  assessed  in 
terms  of  the  need  for:  confidentiality,  integrity  and  availability. 

When  addressing  the  availability  issue,  it  is  important  to  note  that  service 
availability  and  quality  of  service  concepts  are  closely  linked.  Lor  a  critical 
application  that  must  provide  a  certain  level  of  throughput  with  a  minimum 
amount  of  latency  (e.g.  a  voice  over  IP  application),  a  degradation  of 
throughput,  or  reduction  in  quality  of  service  is  operationally  equivalent  to 
loss  of  availability. 
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3.3.2  Extension  Definition 


An  initial  view  of  the  categories  of  assets  in  the  context  of  data  and  processes 
is  presented  in  the  following  table: 


Table  2.  Asset  Categories 


DATA 

PROCESSES 

CONFIDENTIALITY 

Data  elements  can  be  classified 
using  a  set  of  sensitivity  levels. 

This  classification  follows  the  data 
as  it  exists  at  various  points  along 
the  network 

When  data  access  must  be  done 
through  a  specific  process, 
confidentiality  of  that  process  may  be 
relevant. 

Significance:  High 

Significance:  Low 

INTEGRITY 

There  may  be  a  need  to  require 
proof  against  tampering  for  a  data 
element. 

There  may  be  a  need  to  require 
proof  against  tampering  for  a 
process. 

Significance:  Moderate 

Significance:  Moderate 

AVAILABILITY 

When  a  process  is  fed  by  the 
presence  of  data,  the  process 
may  be  faulted  through  the  lack  of 
availability  of  the  data. 

As  per  the  CNDSA  paper,  network 
requirements  can  be  expressed  in 
terms  of  the  need  to  access  data  and 
the  processes  that  act  on  that  data. 

Significance:  Low 

Significance:  High 

This  table  presents  each  of  the  asset  valuations  in  terms  of  its  significance  to 

the  MulVAL  extension  effort.  Significance  is  determined  by: 

a.  The  degree  to  which  the  asset  valuation  is  commonly  associated  with  the 
asset  categories; 

b.  The  ease  by  which  the  current  MulVAL  model  can  include  the  asset 
valuation  element;  and 

c.  The  degree  to  which  the  means  by  which  the  asset  valuation  is 
determined  is  compatible  with  the  MulVAL  approach. 

To  focus  this  investigation,  the  most  significant  asset  valuation  mechanisms 

have  been  addressed,  specifically, 

a.  Application  of  confidentiality  and  integrity  levels  to  data;  and 

b.  Application  of  availability  needs  of  services. 

There  are  two  options  for  associating  C/I  values  to  data:  the  existing  predicate 

dataBind  can  be  extended  or  a  new  predicate  can  be  established  to  specify  a 
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confidentiality/integrity  levels  for  a  data  set.  Both  potential  predicates  are 
presented  below: 

dataBind (Data,  Host,  Path,  Confidentiality,  Integrity) 
dataValue (Data,  Confidentiality,  Integrity) 

For  the  first  option,  the  data  valuation  levels  would  be  associated  with  the 
data  that  is  located  at  the  specified  host/path.  The  second  option  specifies 
that  the  entire  data  set  identified  by  data  would  be  given  a  single 
classification  level.  This  classification  level  could  potentially  apply  to  many 
paths  on  hosts  as  per  the  dataBind  primitives  that  define  the  content  of  the 
data  set. 

To  address  the  availability  component  of  information  asset  value,  the  ideal 
scenario  would  link  the  impact  of  existing  vulnerabilities  to  the  required  level 
of  service  that  must  be  provided  by  applications  in  the  target  environment. 
These  levels  of  impact  can  be  associated  with  an  operational  service  to 
indicate  that  the  service  must  be  able  to  provide  a  level  of  availability  using 
either  an  existing  primitive  or  a  new  one,  as  detailed  below: 

networkServicelnfo (Host,  Program,  Protocol,  Port,  User, 
Availability) 

available (Host,  Program,  Availability) 

Note  that  the  vulProperty  predicate  which  defines  the  impact  of 
vulnerabilities  would  have  to  be  extended  to  include  the  C/I/A  impact  for 
each  vulnerability  in  the  target  environment. 

vulProperty (Cveid,  Range,  Consequence,  Confidentiality, 
Integrity,  Availability) 


3.3.3  Data  Source 

Unfortunately,  data  sensitivity  is  typically  something  that  cannot  be  derived 
from  automated  sources.  The  derivation  of  what  is  sensitive  is  largely  a 
manual  exercise  that  focuses  specifically  on  data  confidentiality,  integrity  and 
availability.  Ref  [1]  includes  Accountability  as  another  measure  of 
sensitivity. 

The  eventual  intent  is  that  military  commanders  can  define  their  computer 
network  needs  in  terms  of  high-level  network  services.  This  can  then  be 
overlaid  on  a  network  to  determine  what  particular  assets  (data,  hardware, 
software,  and  network  links)  are  crucial  to  providing  the  required  services. 

From  the  analysis  perspective,  C/I/A  values  to  be  populated  in  the 
vulProperty  predicate  can  be  obtained  from  the  published  CVSS  vector 
available  through  the  National  Vulnerability  Database.  The  NVD  CVSS 
score  (see  Section  4)  includes  C/I/A  based  metric  that  measures  the  impact  a 
successful  exploit  a  given  vulnerability  will  have  on  the  target  system.  C/I/A 
values  are  expressed  in  terms  of  their  impact  on  a  scale  from:  None  (no 
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impact),  Partial  (some  impact)  to  Full  (significant  impact).  As  an  example, 
the  CVSS  impact  ranking  as  it  applies  to  availability  would  have  the 
following  inteipretation. 

None:  No  impact  on  availability. 

Partial:  Considerable  lag  in  or  interruptions  in  resource  availability.  For 
example,  a  network-based  flood  attack  that  reduces  available  bandwidth  to  a 
web  server  farm  to  such  an  extent  that  only  a  small  number  of  connections 
successfully  complete. 

Complete:  Total  shutdown  of  the  affected  resource.  The  attacker  can  render 
the  resource  completely  unavailable. 

When  populating  the  Datalog  predicates  to  associate  C/I/A  requirement  on 
data  and  services  in  the  target  environment,  there  must  be  commonality 
between  the  values  used  to  express  these  requirements  and  the  values 
available  through  the  CVSS  vector. 

3.3.4  Design  Rationale 

With  the  intent  of  the  chosen  asset  valuation  extensions  in  mind,  the  selection 
of  the  location  to  present  value  data  must  be  in  accord  with  the  elements  to 
which  the  value  applies. 

Confidentiality  and  integrity  values  must  be  associated  with  data  elements  at 
a  level  of  granularity  that  is  suitable  for  the  environment  that  is  being 
modelled.  The  presentation  of  two  options  for  creating  this  association 
provides  sufficient  flexibility  to  achieve  this  needed  level  of  granularity. 

For  example,  a  web  server  application  will  have  information  in  various 
directories,  each  of  which  may  have  different  protection  requirements: 


Table  3.  Example  dataValue  entries  for  a  web  application 


DATATYPE 

LOCATION 

CONF 

INTEG 

PREDICATE 

Executables 

/usr/bin 

None 

Partial 

dataBindfwebdata,  host,  /usr/bin,  none,  partial) 

Data 

/var/www 

High 

Partial 

dataBind(webdata,  host,  /var/www,  high,  partial) 

Configuration 

/etc/ www 

Partial 

Partial 

dataBind(webdata,  host,  /etc/www,  partial,  partial) 

Log 

/var/www/log 

None 

Full 

dataBindfwebdata,  host,  /var/www/log,  none,  full) 

Should  the  second  primitive  be  used,  that  is,  dataValue  which  sets  the 
confidentiality  and  integrity  values  for  a  complete  data  set,  a  sample  primitive 
would  be: 


dataValue (webdata,  high,  full) 
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Note  that  an  attempt  to  determine  the  confidentiality  of  the  data  at  a  specific 
host/path  location  would  always  return  the  high  water  mark  confidentiality 
for  the  entire  data  set. 

hostPathSensitivity (Conf ,  Host,  Path) 
dataValue (Data,  Conf,  Integ) 
dataBind (Data,  Host,  Path) 


The  result  of  using  either  of  these  approaches  is  that  any  analysis  that 
presents  an  attack  path  that  touches  on  data  can  include,  as  part  of  the  output, 
a  statement  of  the  confidentiality  and/or  integrity  impact  of  the  result. 

For  example,  a policyViolation  analysis  that  generates  an  attack  tree  for  cases 
where  an  attacker  can  access  data  will  include  an  identifier  for  the  data  that 
has  been  accessed  in  violation  of  the  policy.  The  results  from  this  analysis 
can  be  ranked  based  on  the  C/I  values  to  identify  those  attacks  that  are  more 
critical  from  an  asset  valuation  perspective.  Note  that  the  valuation  ranking 
can  be  merged  in  with  the  logic  for  visualizing  the  attack  trees  or  included  in 
the  analysis  output  to  allow  sorting/presentation  of  this  ranked  attack  list 
using  external  tools. 

Similarly,  analyses  which  identify  vulnerabilities  (specifically  of  the  denial  of 
service  type)  which  can  be  effectively  used  against  the  environment  can  be 
ranked  based  on  the  relative  importance,  operationally  speaking,  of  the 
service. 

3.3.5  Extension  Critique 

The  enhanced  data  and  network  service  primitives  can  effectively  provide  a 
means  by  which  to  rank  the  relative  importance  of  attacks  against  the  assets 
to  which  these  primitive  apply.  The  fact  that  that  C/I/A  impact  information 
relating  to  vulnerabilities  can  be  obtained  from  the  NVD  implies  that  the 
attack  information  can  be  automatically  generated.  However,  population  of 
asset  valuation  data  as  it  applies  to  data  and  processes  will  remain  a  manual 
process.  This  manual  process  may  limit  the  scalability  of  the  solution  once  a 
large  number  of  data  sets  and  services  are  in  the  target  environment. 

The  NVD  provides  a  limited  set  of  rankings  for  C/I/A  information  and  the 
assignment  of  these  rankings  to  a  specific  vulnerability  is,  to  a  large  extent, 
subjective.  In  the  light  of  the  GoC/GSP,  it  is  not  clear  what  the  implication  of 
“Partial”  integrity  impact  would  be  for  a  specific  data  element  or  service. 
Similarly,  the  available  range  of  impact  for  availability  issues  would  benefit 
from  expansion  to  include  additional  impact  levels.  For  example,  the 
following  set  of  impacts  for  a  denial  of  service  attack  could  be  instituted  as 
each  level  would  have  a  different  implication  in  terms  of  downtime  and  time 
to  recover. 
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level  0:  the  attack  compromises  the  system/network  stack, 
rendering  the  entire  system  unavailable  until  it  is 
restarted. 


level  1:  the  attack  compromises  an  application,  requiring 
the  service  to  be  restarted. 


level  2:  the  attack  does  not  fault  the  application,  but  a 
reduction  in  service  is  incurred. 


level  3:  the  attack  does  not  fault  the  application  and  there 
is  a  minimal  impact  to  the  level  of  service  provided  by  the 
service . 


level  4:  No  availability  impact. 


In  this  scenario,  levels  0  to  1  would  correspond  to  the  NVD’s  interpretation  of 
a  full  impact  for  an  availability  attack.  Levels  2-3  would  correspond  to  the 
NVD’s  interpretation  of  partial  impact  for  an  availability  attack.  The  use, 
however,  of  additional  impact  rankings  would  allow  the  MulVAL  model  to 
reflect  more  detail  in  the  consequences  of  such  an  attack.  There  is  still  the 
need,  however,  for  an  external  source  that  can  provide  this  impact 
information.  For  example,  the  NVD  does  not  include  any  information  about 
availability  attacks  that  can  target  a  service  to  bring  down  the  network  stack 
on  a  target  box.  Such  an  attack  would  have  a  significant  impact  to  all 
services  hosted  on  that  target. 

Once  asset  valuation  is  in  place  in  the  MulVAL  model,  it  would  become 
possible  to  drive  policy  analyses  which  will  match  malicious  users  and  their 
clearance  level  to  classified  information.  For  example,  a  primitive  to  assign  a 
user  a  clearance  level  could  be  expressed  as  follows. 

clearance (userl ,  secret) 

In  this  scenario,  it  would  be  possible  to  produce  attack  trees  whereby  a 
malicious  user  gains  access  to  data  that  is  beyond  that  user’s  clearance  level. 
Note  that  this  attack  does  not  require  the  exploitation  (or  existence)  of  any 
specific  service  vulnerabilities.  That  is,  a  user  can  access  a  local  file  through 
allowed  network  policy,  but  the  user’s  clearance  does  not  meet  the 
classification  level  of  the  data,  a  security  policy  violation  can  be  detected. 

It  is  notable  that  C/I  issues  can  only  be  described  in  the  MulVAL  model  in 
terms  of  violation  of  the  access  control  policy.  There  is  no  representation  in 
the  model  for  protecting  data  in  transit.  However,  availability  can  be 
considered  in  the  context  of  a  multi-hop  transmission  path.  That  is, 
availability  issues  must  consider  the  network  environment  in  which  data  is 
being  transmitted.  A  merging  of  the  Network  MulVAL  extension  that  defines 
firewalls/routers  as  network  devices  with  this  discussion  of  availability  can 
potentially  address  part  of  this  concern  through  the  addition  of  an  availability 
element  to  the  routeEntry  predicate.  An  investigation  into  availability  issues 
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in  terms  of  vulnerable  network  devices,  single  point  of  failure  and  dynamic 
routing  is  recommended. 

As  a  final  point,  it  is  important  to  note  that  attacks  that  impact  availability  are 
focussed  on  software  vulnerabilities  rather  than  network-level  attacks.  This  is 
another  recommended  area  of  investigation  as  the  need  to  recognize  the 
presence  of  network  attacks  (such  as  flooding  attacks)  means  that 
environment  specific  threshold  values  must  be  established  to  differentiate 
between  normal  traffic  and  an  attack. 

Ranking  asset  valuation  using  a  small  range  of  values  on  an  absolute  scale 
can  be  problematic.  For  example,  using  (High,  Medium,  Low)  values  is  not 
sufficient  to  model  the  Government  of  Canada  security  policy  for  both 
classified  and  designated  confidential  assets.  The  classified  (Top  Secret, 
Secret,  Confidential)  and  designated  (Protected  A,  B,  and  C)  scales  are  based 
on  injury  to  the  national  interest  and  individuals/corporations,  respectively. 
Flowever,  when  one  combines  the  scales  in  a  single  absolute  value  range, 
highly  classified  national  interest  material  (for  example,  Top  Secret  Special 
Access)  typically  eclipses  all  other  values.  For  example,  a  viable  absolute 
scale  of  asset  value  for  (TS/SA,  TS,  S,  C,  PC,  PB,  PA,  Unclass)  might  be 
(1.0,  0.9,  0.7,  0.4,  0.3,  0.2,  0.1,  0.001).  This  skewing  towards  highly 
classified  assets  can  then  bury  reasonably  likely  attacks  to  lower  valued  assets 
that  should  be  addressed.  Using  a  relative  asset  value  scale  may  be  necessary 
that  is  specific  to  the  system  being  modelled.  In  these  cases,  MulVAL 
models  of  systems  with  differing  assets  are  not  comparable  from  an  asset 
valuation  or  attack  path  injury  perspective. 


3.4  Attack  Path  MulVAL  Extension 

3.4.1  Objective 

The  objective  of  this  MulVAL  extension  is  to  develop  a  method  of 
prioritizing  attack  path  generation  so  that  MulVAL  users  can  concentrate  on 
remediation  of  the  most  important  potential  attacks,  that  is,  those  with  the 
greatest  impact  to  the  organization. 

Organizational  impact,  or  risk,  is  primarily  a  function  of  two  elements: 

a.  Injun >  to  Asset  Value  based  on  any  successful  attack.  Determining  asset 
value  was  dealt  with  in  Section  3.3  above.  However,  the  injury  a  specific 
attack  causes  to  an  asset  is  only  partially  tracked  in  MulVAL  with  the 
consequence  parameter  in  vuiExists/3  predicate.  This  currently 
specifies  only  one  of  confidentiality,  integrity,  or  availability 
consequences  (in  addition  to  privilege  escalation).  Additional 
information  is  available  from  CVSS  scores  to  provide  a  more  granular 
derivation  of  injury  to  asset  value;  and 
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b.  The  likelihood  of  an  attack  being  successful.  Attack  likelihood  is  a 

complex  function  of  the  probability  of  an  attempted  attack,  the  difficulty 
in  mounting  the  attack,  and  the  capability  of  the  attacker.  Determining 
the  likelihood  of  attack  initiation  is  also  complex  and  fuzzy  based  on  such 
elements  as  attacker  motivation,  potential  injury,  probability  of  detection, 
and  consequences  to  the  attacker.  Determining  attack  success  likelihood 
is  not  possible  in  MulVAL  given  the  lack  of  creditable  sources  of  data  to 
all  the  composite  factors.  However,  MulVAL  could  be  usefully  extended 
to  approximate  likelihood  by  tracking  creditable  data  sources  that  we  can 
access.  Therefore,  the  objective  is  to  approximate  attack  likelihood  by 
tracking  the  difficulty  in  mounting  the  attack  by  using  CVSS  scores. 

Additionally,  this  MulVAL  extension  requires  the  ability  to  order  attack  trees 
in  a  manner  that  makes  organizational  impact  readily  evident. 


3.4.2  Extension  Definition 

A  suitable  MulVAL  extension  could  not  be  developed  during  the  project 
timeframe. 


3.4.3  Data  Source 

The  originally  proposed  data  sources  for  modelling  asset  injury  [2]  were  the 
following  CVSS  base  scores: 

a.  Confidentiality  (None,  Partial,  and  Complete); 

b.  Integrity  (None,  Partial,  Complete); 

c.  Availability  (None,  Partial,  Complete);  and 

d.  Bias  (Normal,  Confidentiality,  Integrity,  and  Availability). 

The  NVD  CVSS  analysis  in  Section  4  below,  shows  that  these  values  are 
tracked  for  tracked  for  nearly  all  NVD  tracked  vulnerabilities.  The  bias  score 
is  of  little  use  since  >99%  of  all  values  are  normal  (that  is,  confidentiality, 
integrity  and  availability  are  equally  biased  in  injury).  The  values  of  C/I/A 
tend  to  be  clustered  into  the  following  groupings: 

a.  Complete  injury  to  all  of  C/I/A; 

b.  Partial  injury  to  all  of  C/I/A; 

c.  Complete  injury  to  just  C; 

d.  Complete  injury  to  just  I;  and 

e.  Complete  injury  to  just  A. 
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The  originally  proposed  data  sources  for  modelling  the  likelihood  of 
successful  attacks  [2]  were  the  following  CVSS  scores: 

a.  accessComplexity  (High,  Low)  from  the  base  CVSS  score; 

b.  authentic ationRequired  (Required,  Not  Required)  from  the  base  CVSS 
score; 

c.  exploitability  (Unproven,  Proof-of-concept,  Functional)  from  the 
temporal  CVSS  score;  and 

d.  reportConfidence  (Unconfirmed,  Uncorroborated,  Confirmed)  from  the 
temporal  CVSS  score. 

The  NVD  CVSS  analysis  in  Section  4  below  shows  that  temporal  CVSS 
scores  are  not  currently  tracked  in  NVD  although  the  database  has  the 
capability  to  carry  this  data  in  its  schema. 

Additionally,  analysis  of  the  values  recorded  for  the  two  CVSS  base  scores 
show  that  they  are  heavily  biased  to  a  single  data  value,  which  decreases  the 
element’s  usefulness  in  determining  attack  pattern  likelihood: 

a.  Greater  than  97%  of  vulnerabilities  have  an  accessComplexity  of  Low, 
and 

b.  Greater  than  99%  of  vulnerabilities  have  an  authenticationRequired  of 
Not  Required. 

Therefore,  from  a  creditable  data  source  perspective,  there  is  only  data 
available  that  allows  a  more  granular  determination  of  asset  injury  in  a 
MulVAL  extension.  All  the  data  sources  for  determining  attack  likelihood 
either  don’t  exist  or  provide  no  discemable  value. 

3.4.4  Design  Rationale 

MulVAL  models  attack  paths  as  sequences  of  attack  steps  that  may  have  local 
asset  consequences  but  mainly  lead  to  other  attack  steps.  The  question  of 
when  one  stops  the  attack  sequence  to  cause  injury  to  the  final  set  of  assets 
resident  at  the  final  attack  step  remains.  From  an  attacker  perspective,  it 
depends  on  their  motivation: 

a.  If  system  exploration  is  the  motive,  then  the  attack  paths  will  not  end 
until  all  aspects  of  the  system  are  compromised;  or 

b.  If  organizational  injury  is  the  motive,  then  the  attack  will  terminate  when 
the  attacker  has  achieved  their  objective  of  impacting  some  targeted  asset. 
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From  a  defender  perspective,  the  attacks  of  greatest  concern  are  those  that 
cause  the  greatest  injury  to  the  organizational  assets.  Although  this  can  be 
aligned  with  the  second  attacker  motive  above,  it  may  not  be  based  on  the 
attacker  and  defender  having  differing  views  of  organizational  injury. 

So  a  MulVAL  attack  pattern  is  made  up  of  a  number  of  steps,  which 
ultimately  lead  to  injury  to  a  valued  asset.  In  order  to  prioritize  all  the  attack 
paths  one  must  find  final  step  vulnerabilities  in  viable  attack  patterns  that  lead 
to  unacceptable  injury.  These  attack  patterns  can  be  further  prioritized  by 
determining  the  difficulty,  or  path  resistance,  in  completing  all  the  steps  in  the 
attack  pattern. 

It  is  not  clear  at  this  time  how  the  different  steps  should  be  combined  to 
determine  an  overall  difficulty  value  for  the  attack  pattern.  Possible 
mathematics  include:  summation  of  step  difficulty,  product  of  step  difficulty, 
or  high/low  water  marks. 

Further  research  is  needed  in  the  type  of  factors  that  might  influence  the 
determination  of  attack  step  difficulty,  which  might  include: 

a.  Attack  complexity.  Here  we  try  to  rate  the  complexity  of  mounting  the 
attack  step.  Although  NVD  currently  tracks  this  CVSS  base  score,  the 
data  present  is  of  limited  value  being  mainly  low.  Note  that  CVSS  is 
considering  adding  an  intermediate  value  which  may  make  this  CVSS 
score  more  useful  in  determining  MulVAL  attack  step  difficulty; 

b.  Availability  of  exploit  code.  Although  CVSS  temporal  scores  track  this 
notion,  this  data  is  not  populated  in  the  NVD.  There  is  a  danger  that  the 
public  knowledge  of  available  exploit  code  does  not  reflect  secretly  held 
exploit  code  developed  within  the  hacker  or  Information  Operations 
adversary  fields; 

c.  More  detail  on  what  type  of  authentication,  if  any,  is  required.  CVSS 
base  scores  currently  have  an  authentication-required  value,  although 
most  of  the  vulnerabilities  listed  do  not  require  authentication. 
Furthermore,  in  the  cases  where  authentication  is  required,  MulVAL 
already  tracks  prior  attack  steps  which  provide  privilege  escalation  to  a 
useable  account  in  the  current  attack  step; 

d.  Attack  Path  Length.  The  overall  number  of  steps  and  complexity  in 
sequencing  an  attack  pattern  may  provide  an  element  of  difficulty  for 
human  attackers;  however,  automated  scripting  of  attack  patterns  and 
automated  attack  tools  ameliorate  this  difficulty;  and 

e.  Attack  Execution  Time.  Some  attack  steps  may  take  a  determinate 
amount  of  time  to  complete  based  on  the  resistance  of  underlying 
safeguards.  Two  examples  are:  cryptanalysis  and  password  cracking. 
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Attack  execution  time  seems  to  be  related  to  underlying  preventative 
safeguards. 


3.4.5  Extension  Critique 

A  suitable  MulVAL  extension  could  not  be  developed  during  the  project 
timeframe. 
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4.  MulVAL  Model  Observations 


While  working  closely  with  the  definition  and  composition  of  MulVAL  model 
elements,  some  observations  were  made  with  regards  to  model  behaviour  which  may 
warrant  further  investigation.  These  observations  are  listed  below. 

1 .  There  is  no  examination  of  the  scenario  where  a  vulnerable  network  service  is 
operating  under  a  program  that  is,  itself,  identified  as  being  setuid  enabled. 

2.  Under  conditions  where  a  program  supports  both  TCP  and  UDP  protocols  (e.g. 
DNS),  this  single  program  will  be  associated  with  both  network  services.  If  a 
vulnerability  exists  within  that  program,  but  only  applies  to  one  of  these  protocols, 
MulVAL  will  incorrectly  report  that  the  program  is  vulnerable  though  either 
protocol. 
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5.  NVD  CVSS  Observations 

The  US  National  Institute  of  Science  and  Technology  (NIST)  maintains  the  NVD  on¬ 
line  database  of  vulnerabilities.  This  database  ties  together  vulnerability  data  from  a 
number  of  sources  in  a  standardized  schema. 

The  current  MulVAL  data  model  relies  on  the  exploit  range  (local  or  remote)  and  the 
privilege  escalation  consequence  data  that  were  previously  stored  on  the  ICAT 
database,  but  are  now  stored  in  NVD.  Note  that  ICAT  data  has  been  integrated  into 
NVD  and  ICAT  format  data  output  will  be  deprecated  sometime  in  the  future. 

The  Asset  and  Attack  Weight  MulVAL  Extensions  also  rely  on  the  CVSS  values 
contained  in  NVD.  As  noted  in  the  DAP  Report  [2],  CVSS  provides  the  following: 

a.  The  CVSS  base  scores  Confidentiality,  Integrity,  and  Availability  provide  an 
indication  of  the  degree  of  impact  (None,  Partial,  and  Complete)  a  vulnerability 
has.  The  Bias  information  indicates  the  general  impact  weighting  between  these 
three  asset  values  (Normal,  or  C/I/A  biased);  and 

b.  The  CVSS  base  scores  for  Access  Complexity  (High,  Low)  and  authentication 
required  (Yes,  No)  could  be  used  to  eliminate  attack  success  by  non-capable 
threat  agents.  Also  the  CVSS  temporal  scores  for  exploitability  (unproven,  proof- 
of-concept,  and  functional),  and  the  report  confidence  (unconfirmed, 
uncorroborated,  and  confirmed)  could  be  used  to  determine  the  probability  of 
success  of  an  attack. 

Since  the  NVD  and  its  CVSS  scores  are  critical  data  sources  for  MulVAL  extensions, 
a  quick  analysis  was  performed  on  the  NVD  CVSS  scores5.  The  results  are  as 
follows: 

a.  The  NVD  currently  contains  15,828  vulnerabilities  from  2002  to  present.  Of 
these,  CVSS  scores  were  provided  for  all  but  234  entries  which  were  blank; 

b.  The  NVD  currently  only  contains  CVSS  base  scores.  The  NVD  website  notes 
that  CVSS  temporal  scores  can  also  be  tracked,  but  no  temporal  data  exists.  The 
NVD  contains  the  entire  CVSS  base  score  vector  in  the  format 
“(AV:R/AC:L/Au:NR/C:N/I:N/A:C/B:N)”,  which  corresponds  to:  Access  Vector 
(Local  or  Remote),  Access  Complexity  (Low  or  High),  Authentication  Required 
(Not  Required  or  Required),  Confidentiality  (None,  Partial,  or  Complete), 
Integrity  (None,  Partial,  or  Complete),  Availability  (None,  Partial,  or  Complete), 
and  Bias  (Normal,  Confidentiality,  Integrity,  or  Availability); 

c.  Two  CVSS  scores  were  heavily  biased  to  a  single  data  value  that  their  use  in 
MulVAL  extension  is  questionable:  over  99%  of  all  vulnerabilities  did  not  require 
authentication  and  had  a  normal  impact  bias; 


5  The  NVD  database  was  downloaded  and  analyzed  on  15  March,  2006. 
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d.  Additionally,  the  Access  Complexity  score  was  heavily  biased  towards  a  single 
answer:  over  97%  of  all  vulnerabilities  have  a  low  access  complexity; 

e.  25%  of  vulnerabilities  are  listed  as  local  and  the  remaining  75%  can  be  initiated 
remotely; 

f.  As  shown  in  pivot  Table  4,  for  most  of  the  vulnerabilities  in  NVD  (that  is,  those 
with  low  complexity  and  no  authentication  required),  the  asset  value  impacts  are 
not  evenly  distributed  but  rather  clustered  with  the  majority  of  vulnerabilities 
(83%)  having  either:  Complete  impact  in  C/I/A  (15%),  only  C  impact  (12%), 
only  I  impact  (10%),  only  A  impact  (16%),  or  partial  impact  in  C/I/A  (30%). 
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Table  4.  Pivot  table  of  C/I/A  impacts 


CONF 

INT 

AVAIL 

AV:L 

AV:R 

GRAND 

TOTAL 

C:C 

l:C 

A:C 

33.01% 

9.14% 

14.80% 

A:N 

1 .40% 

1.14% 

1 .20% 

A:P 

0.25% 

0.29% 

0.28% 

l:N 

A-.C 

0.20% 

0.31% 

0.29% 

A:N 

9.15% 

12.77% 

11.91% 

i.P 

A:C 

0.00% 

0.03% 

0.03% 

A:P 

2.10% 

1.50% 

1.64% 

C:N 

l:C 

A:C 

0.53% 

0.33% 

0.38% 

A:N 

9.57% 

10.66% 

10.40% 

T.N 

A:C 

9.66% 

17.55% 

15.68% 

A:P 

0.42% 

1 .42% 

1.18% 

l:P 

A:N 

0.81% 

5.48% 

4.38% 

A:P 

0.06% 

0.10% 

0.09% 

C.P 

l:C 

A-.C 

0.08% 

0.07% 

0.07% 

A-.P 

2.46% 

2.45% 

2.46% 

T.N 

A:N 

1 .04% 

1.90% 

1 .69% 

A-.P 

0.03% 

0.06% 

0.05% 

TP 

A-.C 

1 .34% 

3.77% 

3.19% 

A-.N 

0.08% 

0.49% 

0.39% 

A-.P 

27.80% 

30.53% 

29.88% 

Grand  Total 

100.00% 

100.00% 

100.00% 
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6.  Conclusion 

This  paper  has  demonstrated  that  the  MulVAL  model  is  extensible  and  can  be 
enhanced  to  include  additional  data  representation  and  analysis  features  to  tailor  the 
model  to  a  specific  problem  environment.  Specifically,  the  extensions  which  were 
proposed  in  the  Dynamic  Asset  Protection  &  Risk  Management  Abstraction  Study 
have  been  shown  to  be  both  technically  valid  given  the  capabilities  of  logic-based 
programming,  but  also  appropriate  given  the  current  MulVAL  model  data 
representations.  This  paper  documented  a  substantial  degree  of  progress  in  the 
development  of  each  of  the  proposed  MulVAL  extensions,  as  detailed  below. 

a.  The  network  MulVAL  extension  demonstrated  that  it  is  possible  to  extend  the 
simplistic  host  access  control  list,  currently  defined  in  the  existing  MulVAL 
model,  with  a  more  intuitive  approach  that  more  appropriately  reflects  real- 
network  design.  The  ability  to  represent  hosts  on  one  or  more  subnets,  network 
devices  that  gate  access  between  subnets,  and  routes  between  subnets  provides  a 
great  deal  of  flexibility  for  the  creation  of  new  assertions  to  capture  the  true 
network  and  dataflow  configuration. 

b.  The  asset  value  extension  demonstrated  that  it  is  possible  to  extend  existing 
predicates  to  include  additional  characteristics  for  improved  representation  of  the 
environment  being  modelled.  By  drawing  upon  industry  accepted  practices  for 
the  definition  of  data  and  service  value,  a  view  of  the  model  can  be  made  which  is 
more  consistent  with  established  data  valuation  practices.  The  impact  of 
vulnerabilities  in  the  target  environment  can  be  expressed  in  a  context  that  is 
more  easily  understood  by  security  professionals.  Given  the  ability  to  assign  a 
valuation  to  data,  the  tools  are  in  place  to  prioritize  the  attack  paths  which  are 
established  though  a  MulVAL  analysis. 

c.  This  paper  provided  not  only  a  theoretical  evaluation  of  potential  extensions  for 
the  MulVAL  model,  but  also  the  design  and  implementation  of  actual  predicates 
that  instantiate  the  extensions  as  defined.  Testing  was  undertaken  to  prove  the 
actual  operation  of  some  of  the  proposed  model  extensions. 

This  paper  proposes  that  additional  effort  to  refine  the  MulVAL  extensions  will  lead 
to  a  complete  set  of  valid  and  appropriate  enhancements  to  the  model.  Specifically,  it 
is  proposed  that  the  following  tasks  be  undertaken  to  progress  this  effort. 

a.  Further  enhance  the  attack  path  extension  to  determine  how  the  different  attack 
difficulty  assessments  /  valuation  methods  should  be  combined  to  determine  an 
overall  difficulty  value  for  the  attack  pattern; 

b.  Perform  more  data  instantiation  for  all  proposed  model  extensions  to  prove  the 
validation  of  the  approach  (in  the  spirit  of  the  work  that  was  done  for  the  network 
MulVAL  extension);  and 

c.  Assess  the  need  for  and  identify  any  additional  extensions. 
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As  a  final  point,  it  is  recommended  that  the  work  on  MulVAL  extensions  be  shared 
with  the  MulVAL  development  team  so  as  to  establish  a  useful  dialogue  for  the 
further  development  of  extensions  and  returning  feedback  to  the  model  originators. 
Also,  any  work  to  be  done  on  model  extension  should  be  made  in  the  context  of 
industry  best  practices  and  security  community  resources  (e.g.  the  NVD).  This  will 
assist  in  making  the  MulVAL  analysis  relevant  for  security  professionals  and  accurate 
for  military  applications. 
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Annex  A  -  MulVAL,  Skybox,  and  CycSecure  Critique 


The  presentation  of  the  analysis  is  done  in  two  large  tables: 

a.  Annex  A  -  Table  1  -  Tool  Set  Architecture  provides  a  comparative  view  of  all 
three  tools  with  regard  to:  information  available,  network  model  collection, 
vulnerability  knowledge,  information  analysis,  information  presentation, 
performance  of  information  collection,  performance  of  information  analysis,  and 
scalability;  and 

b.  Annex  A  -  Table  2  -  Critique  of  Toolsets  in  Providing  DAP  Abstraction 
Requirements.  This  table  has  identical  rows  to  the  MulVAL  critique  in  [2],  The 
table  has  three  columns  for  each  of  MulVAL,  Skybox,  and  CycSecure.  The 
MulVAL  critique  is  largely  that  provided  in  [2]  with  some  minor  updates.  The 
Skybox  and  CycSecure  critiques  are  new. 

The  two  tables  are  presented  in  landscape  format  due  to  the  size  of  their  columns. 
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Table  5.  Tool  Set  Architectures 


MULVAL 

SKYBOX 

CYCSECURE 

Information  Available 

•  Excellent  technical  information 

•  Limited  technical  information 

•  Good  technical  information 

•  Refereed  paper  [4] 

•  Marketing  Material  only  [7],  [8],  [9],  [10], 

•  Refereed  paper  [15] 

[11],  and  [12] 

Architecture  - 

•  All  information  represented  as  Datalog 

•  Imports  all  information  from  external 

•  Built  in  network  based  vulnerability 

Network  Model  Collection 

facts 

sources  except  for  the  View  Dictionary, 
which  comes  from  Skybox 

scanner  [14] 

•  Uses  Mitre  reference  OVAL  host-based 

•  Uses  host-based  scanners  called  Sentinels 

scanner  with  custom  code  to  translate  to 

•  Supported  scanners  are  predominantly 

which  are  polled  from  central  server  [15] 

Datalog  [4] 

support  network-based  and  not  host-based 
vulnerability  scanning 

•  Sentinels  gather  information  on  software, 

•  Policy  is  manually  input  and  assumed  to 

hardware,  and  machine  status. 

be  small 

•  Asset  classification  can  be  imported  from 

other  [manually  generated]  asset 

•  Hacl/4  appears  to  be  manually  input  and 

information  sources 

assumes  a  fairly  static  network 
configuration 

•  Network  configuration  can  be  imported 

from  firewalls,  routers  and  load  balancers 

Architecture  -  Vulnerability 

•  OVAL  vulnerability  notifications 

•  Skybox  provides  the  View  Dictionary, 

•  CERT  and  BugTraq  information  sources 

Knowledge 

•  Datalog  parsed  from  OVAL  schema 

which  contains  vulnerability  information 

•  Requires  trained  ontologist  to  adapt 

•  No  information  on  sources 

knowledge  base 
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Table  5.  Tool  Set  Architectures 


MULVAL 

SKYBOX 

CYCSECURE 

Architecture  - 
Information  Analysis 

•  Prolog  logic  reasoning  based  on  Datalog 
facts  and  Datalog  reasoning  rules  which 
searches  for  attack  paths 

•  Attack  path  analysis  reasoning  not 
provided 

•  Uses  Cyc  common  sense  knowledge  base 
and  reasoning  system  [15] 

•  Uses  a  CERT  and  BugTraq  populated 
Computing  domain  knowledge  base 

•  Uses  a  Sentinel  (and  network  scanner?) 
populated  network  model  knowledge  base 

•  Uses  Cyc  inference  engine  to  reason 
across  3  knowledge  bases 

Architecture  - 
Information  Presentation 

•  Command  line  text  output  with  tracing  of 
attack  logic  [4] 

•  No  GUI  output  capability 

•  GUI  presentation  [8] 

•  Simple  attack  path  diagrams  [8] 

•  Dynamic  HTML  user  interface  that  is 
textual  in  common  language  [15] 

Performance  - 
Information  Collection 

•  Near  real-time  collection 

•  Collection  performed  on  hosts,  therefore 
parallel  operation  for  arbitrary  network  size 

•  236  seconds  for  a  Red  Hat  Linux  9  host 
running  on  a  Pill  730MHz  processor  with 
128MB  RAM.  [4] 

•  Collection  done  outside  Skybox  and 
imported 

•  Most  supported  vulnerability  scanners  are 
network  based,  therefore,  scan  time  would 
increase  with  network  size 

•  No  timing  information  provided 

•  Collection  performed  using  a  non- 
disruptive  network  scanner  [14]  and 
Sentinels  [15] 

•  Network  scan  time  would  increase  with 
network  size 

•  Multiple  Sentinel  scanning  could  be  done 
concurrently 

•  No  timing  information  provided 

DRDC  Ottawa  CR  2006-251 


37 


Table  5.  Tool  Set  Architectures 


MULVAL 

SKYBOX 

CYCSECURE 

Performance  - 
Information  Analysis 

•  Near  real-time  reasoning  using  Windows 
2.8GHz  PC  over  large  networks  [4] 

•  0.22  seconds  -  200  hosts 

•  0.75  seconds  -  400  hosts 

•  3.85  seconds  -  1000  hosts 

•  15.8  seconds  -  2000  hosts 

•  No  timing  information  provided 

•  “[Attack]  Plan  generation  takes  on  the 
order  of  minutes  (or,  in  the  case  of  very 
complex  plans,  a  few  hours)”  [15] 

•  No  timing  context  given  (that  is,  model 
size,  server  hardware,  etc.) 

Scalability 

•  Large  network  capable 

•  Appears  to  have  an  exponential  rise  in 
analysis  time 

•  Scalability  information  not  provided 

•  Inference  engine  uses  multi-bindings  to 
treat  similar  instances  of  vulnerabilities  as 
a  class  in  attack  analysis 

•  “dynamic  multi-bindings  enables  [attack] 
planning  times  to  remain  relatively 
independent  of  network  size.”  [15] 

•  Large  network  capable 
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The  following  table  provides  a  critique  of  three  potential  technologies  for  providing  DAP  Abstraction  requirements: 


Table  6.  Critique  of  Toolsets  in  Providing  DAP  Abstraction  Requirements 


DAP  REQUIREMENT 

MULVAL  CRITIQUE 

SKYBOX  CRITIQUE 

CYCSECURE  CRITIQUE 

Map  mission-required  IT  Services 
onto  computer  network  resources 

•  None  of  the  tools  models  mission-required  IT  services  explicitly,  where  an  IT  service  implies  data  as  well  as  any  required  processing  of  that 
data. 

•  MulVAL  models  data  assets  but  without 
explicit  value 

•  Skybox  models  data  assets  in  monetary 
value,  C/I/A,  or  risk  scale  (high/med/low) 

•  CycSecure  does  not  appear  to  model  data 
assets  [15] 

Combine  computer  network 
resources  into  IT  Service  offerings 
that  support  a  required 
confidentiality,  integrity,  and 
availability  Quality  of  Service  (QoS) 

•  MulVAL  implies  that  data  is  the  asset 
needing  protecting  as  evidenced  in  the 
policy  Datalog  fact. 

•  MulVAL  does  not  model  asset  sensitivity  or 
value.  Therefore,  all  data  assets  are  of 
equal  implied  value 

•  MulVAL  does  model  IT  services  as  assets 
(at  least  not  in  their  policy  facts).  However, 
MulVAL  reasoning  does  identify  C/I/A 
impacts  to  data,  which  might  be 
extendable  to  IT  Services. 

•  Skybox  appears  to  model  assets  from  a 
C/I/A  perspective  through  the  importation 
of  externally  defined  asset  classification 
data  sources. 

•  Asset  valuation  is  implied  through  impact 
rules  using  monetary,  risk  scale  (high  - 
medium  -  low),  C/I/A,  or  regulatory 
compliance. 

•  The  above  marketing  literature  statement 
is  unclear  whether  several  scales  may  be 
used  in  each  of  the  C/I/A  areas. 

•  CycSecure  appears  to  model  asset  value 
since  it  alludes  to  identifying  attacks 
“having  the  most  serious  overall 
consequences.”  [14] 

•  Calculating  consequences  is  determining 
impact  on  assets  and  this  implies  knowing 
asset  values. 

•  Conflicting  information  with  [15]. 

Describe  computer  network 
resources  as  interdependent 
elements 

•  MulVAL  sufficiently  handles  the 

interdependency  of  hosts,  programs, 
services,  data,  and  network  connectivity. 

•  MulVAL  does  not  model  network  elements 
explicitly,  which  can  also  be  sources  of 
vulnerability  (for  example,  firewalls  and 
routers). 

•  Skybox  models  the  interdependencies  of 
network  elements  such  as:  filtering  routers, 
firewalls,  hosts,  and  servers. 

•  It  is  unclear  whether  Skybox  can  explicitly 
model  logical  elements  internal  to  a  host  or 
server  (for  example,  different  processes) 

•  CycSecure  models  the  interdependency  of 
network  elements.  [15] 

•  CycSecure  models  logical  elements 
internal  to  hosts  and  servers  using  Sentinel 
host-based  scanning.  [15] 
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Table  6.  Critique  of  Toolsets  in  Providing  DAP  Abstraction  Requirements 


DAP  REQUIREMENT 

MULVAL  CRITIQUE 

SKYBOX  CRITIQUE 

CYCSECURE  CRITIQUE 

Describe  vulnerabilities  as  attributes 
of  computer  network  resources 

•  MulVAL  adequately  describes 

vulnerabilities  as  attributes  of  software 
programs. 

•  Operating  system  kernel  vulnerabilities  are 
modelled  as  a  setuidProgram/3  and  a 
networkServicelnfo/5. 

•  MulVAL  does  not  model  human  behaviour 
as  vulnerability  in  social  engineering 
attacks. 

•  Skybox  relies  on  external  tools  to  provide 

vulnerability  information.  Skybox  supports 
market  leading  network  vulnerability 

scanners,  which  all  have  limited,  if  any, 
host  based  scanning  capabilities. 

•  Given  the  dependency  on  these  external 

tools,  Skybox  appears  to  model  network 
visible  vulnerabilities,  and  may  be  able  to 
model  aspects  of  internal  host 

vulnerabilities. 

•  CycSecure  collects  and  models 

vulnerabilities. 

•  Ontology  includes:  354  classes  of  software 
faults,  683  classes  of  vulnerability,  and 
12409  computer  programs. 

Describe  security  safeguards  as 
attributes  of  computer  network 
resources 

•  None  of  the  models  appear  to  handle  detection,  containment,  or  recovery  safeguards. 

•  None  of  the  models  appear  to  deal  with  human  behaviour  as  safeguards. 

•  MulVAL  implies  only  some  prevention 

safeguards  using  hacl/4,  filePath, 
accessFile/4,  nfsExport/4,  and 

nfsMountTable/5  Datalog  facts. 

•  MulVAL  explicitly  models  data  file  access 
rights  but  not  program  access  controls. 

•  MulVAL  only  models  owner  access 
controls  to  data  and  not  world,  group,  or 
ACL  access  controls. 

•  It  is  unclear  how  or  if  Skybox  models 
application  safeguards. 

•  With  importing  data  from  host-based 
scanners,  or  from  network  management 
tools,  Skybox  may  be  able  to  model  some 
forms  of  application  safeguards. 

•  It  is  unclear  how  or  if  CycSecure  models 
application  safeguards. 

•  MulVAL  models  all  network  connectivity  in 
hacl/4  rules,  which  imply  filtering  router 
and  firewall  configurations. 

•  MulVAL  needs  an  extension  that  models 
network  element  safeguards  explicitly. 

•  Skybox  models  network  filtering  routers 
and  firewalls  explicitly  by  importing  their 
configurations. 

•  It  is  assumed  that  Sentinels  need  to  run  on 
routers  and  firewalls  in  order  to  gather 
network  connectivity  safeguards  as  implied 
in  the  statement  “Sentinels  ...  run  on  each 
machine  on  the  target  network”  [15] 
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Table  6.  Critique  of  Toolsets  in  Providing  DAP  Abstraction  Requirements 


DAP  REQUIREMENT 

MULVAL  CRITIQUE 

SKYBOX  CRITIQUE 

CYCSECURE  CRITIQUE 

Map  threat  events  onto  computer 
network  resources  with  vulnerability 
and  safeguard  attributes 

•  All  of  the  tools  explicitly  model  vulnerabilities  as  threat  events,  or  steps  in  an  attack. 

•  All  of  the  tools  appear  to  model  safeguards  as  the  lack  of  vulnerabilities  in  attack  paths. 

•  None  of  the  models  appear  to  model  threat  agent  capability 

•  MulVAL  models  attacker  intent  using 
malicious/1  but  does  not  model  other 
attacker  motivations  (for  example, 
detection  avoidance) 

•  Attack  paths  only  start  from  malicious/1 
entities  (that  is,  attackers) 

•  Skybox  models  Threat  Origins  as  “profiles 
of  all  potential  sources  of  attack” 

•  It  is  not  clear  what  aspects  of  threat  origins 
are  modelled,  or  how  this  information  is 
generated. 

•  It  is  not  clear  if  Skybox’s  attack  scenarios 
are  limited  to  only  those  originating  from 
known  threat  origins  (versus  all  possible 
attack  paths). 

•  CycSecure  does  not  appear  to  model 
threat  agents  explicitly. 

•  It  is  unclear  how  CycSecure  determines 
the  origins  of  network  attacks,  yet  an 
attack  plan  can  be  built  using  the  term 
“hypothetical  hacker”  [15] 

•  MulVAL  models  the  probability  of 
vulnerability  exploitation  as  1  provided  an 
attacker  could  gain  access  to  the 
vulnerability. 

•  Skybox  appears  to  calculate  probabilities 
of  attacks  in  the  statement  “The  Attack 
Simulation  Engine  computes  the  likelihood 
of  attacks.” 

•  CycSecure  appears  to  model  the 
probability  of  vulnerability  exploitation  as  1 
provided  an  attacker  could  gain  access  to 
the  vulnerability. 

•  It  is  not  clear  whether  this  likelihood 
applies  to  individual  vulnerabilities  being 
exploited,  or  to  entire  attack  paths. 

•  As  above,  it  is  not  clear  how  CycSecure 
determines  the  starting  location  of  attacks. 

•  It  is  not  clear  how  these  probabilities  are 
calculated. 

Relate  threat  events  to  safeguard 
effectiveness  and  vulnerabilities 

•  All  of  the  tools  model  preventative  safeguards  only,  and  generally  as  a  lack  of  vulnerabilities. 

•  None  of  the  tools  seems  to  model  safeguards  effectiveness  in  the  face  of  specific  threat  events. 
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Table  6.  Critique  of  Toolsets  in  Providing  DAP  Abstraction  Requirements 


DAP  REQUIREMENT 

MULVAL  CRITIQUE 

SKYBOX  CRITIQUE 

CYCSECURE  CRITIQUE 

Show  physical  and  logical  network 
connectivity  (as  possible  attack 
ingress  paths)  as  graphs  of  nodes 
and  links 

•  None  of  the  tools  models  the  Physical  Layer. 

•  All  of  the  tools  model  the  Logical  Layer. 

•  The  MulVAL  logical  model  is  fairly 
complete  since  it  uses  a  host-based 
scanner. 

•  The  Skybox  logical  model  is  limited  by  the 
3rd  party  firewall  and  router  configurations, 
and  network  vulnerability  scanner  output. 

•  The  CycSecure  logical  model  is  fairly 
complete  since  it  uses  a  host-based 
scanner. 

•  It  appears  that  CycSecure  models  similar 
host  information  to  MulVAL  (“...programs 
installed  or  running  ...  privileges  the 
running  programs  have  ...  what  users  are 
logged  into  ...  parameters  of  critical 
operations  system  files”)  [15]. 

Map  sequences  of  threat  events  into 
threat  vectors  applied  to  the 
computer  network  resource 
connectivity 

•  MulVAL  includes  a  host  based  vulnerability 
scanner  based  on  the  open  source  OVAL 
scanner  that  outputs  Datalog  facts 
according  to  the  MulVAL  data  model. 

•  Skybox  has  no  integral  method  of 
determining  vulnerabilities  but  can  import 
network  and  host  based  vulnerability 
scanning  data. 

•  CycSecure  includes  custom  host-based 
scanners,  which  are  polled  from  a  central 
server. 

•  MulVAL  models  attack  profiles  well, 
including  complex  attacks  involving  both 
remotely  exploitable  and  local  privilege 
escalation  vulnerabilities. 

•  It  is  unclear  from  Skybox  marketing 
information  whether  privilege  escalation 
vulnerabilities  found  by  host-based 
scanners  can  be  integrated  into  multi-stage 
attacks,  since  this  requires  a  uniformity  of 
data  model,  which  may  or  may  not  be 
present  in  Skybox.  The  Skybox 

vulnerability  dictionary  may  carry 
translation  information  from  supported 
scanners  into  a  common  data  model. 

•  CycSecure  uses  the  network  model, 
computing  domain  (vulnerability),  and 
common  sense  knowledge  bases  to 
reason  on  attack  plans. 

•  The  CycSecure  ontology  is  much  more 
complex  than  MulVAL’s  so  it  may  have 
better  reasoning  on  attack  paths;  however, 
more  information  is  needed  to  confirm  this 
hypothesis. 

•  Therefore,  it  is  unclear  whether  Skybox 
can  model  attack  profiles  to  the  extent  that 
MulVAL  can. 

Map  areas  of  responsibility  onto  IT 

•  Organizational  responsibility  is  not  a  model  requirement  at  this  time. 
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Table  6.  Critique  of  Toolsets  in  Providing  DAP  Abstraction  Requirements 


DAP  REQUIREMENT 

MULVAL  CRITIQUE 

SKYBOX  CRITIQUE 

CYCSECURE  CRITIQUE 

Services  and  computer  network 
resources 

•  MulVAL  does  not  model  responsibility. 

•  Skybox  appears  to  model  business  units 
(“[Risk]  metrics  are  consolidated  for 
individual  Business  Units.”),  based  on 
server/application  ownership. 

•  CycSecure  does  not  model  responsibility. 

Generally  decompose  a  large 
computer  network  into  smaller 
computer  networks 

•  None  of  the  tools  explicitly  handle  network  decomposition. 

•  It  is  assumed  that  MulVAL  and  Skybox  can  model  groups  of  entities  as  a  class  in  order  to 
simplify  the  network  model,  provided  their  attributes  are  identical  (for  example,  multiple 
legitimate  users  or  hosts). 

•  CycSecure  explicitly  models  all  network 
elements  (for  which  it  has  installed 
Sentinels. 

•  Classing  of  elements  in  attack  plan 
generation  is  handled  dynamically  using 
multi-bindings  [15]. 

•  MulVAL  implicitly  decomposes  networking 
infrastructure  into  a  set  of  hacl/4  Datalog 
facts  that  defines  TCP/IP  connectivity 
between  any  two  hosts.  Therefore, 

network  makeup  (firewalls,  routers,  links, 
LANs,  etc)  is  embodied  in  the  hacl/4  rules. 

•  Skybox  explicitly  models  networking 
infrastructure  elements. 

•  CycSecure  appears  to  model  networking 
infrastructure  elements. 

Support  geographic  representations 
of  computer  network  physical 
components 

•  None  of  the  tools  models  the  physical  domain. 

•  Geographic  modelling  is  not  seen  as  a  requirement  at  this  time. 

Support  layered  abstraction  based 
on  service  definitions  in  order  to 
support  coalition  networks,  joint  task 
force  networks,  and  externally 
provided  computer  network  services 
such  as  Internet  Service  Providers 
(ISPs)  and  satellite  providers 

•  It  is  not  clear  if  DAP  requires  modelling  abstraction  at  this  time. 

•  None  of  the  tools  appear  to  support  layered  model  abstractions. 
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Annex  B  -  MulVAL  Network  Extension 


Net_rules_schema.P  listing: 

%  Copyright  (C)  2006  Defence  R&D  Canada 
%  MulVAL  interaction  rules  for  mapping  networks . 

%  Author  :  Mike  Froh 

/*******************************************************/ 

/****  Primitive  predicates  *****/ 

/*******************************************************/ 

primitive (hostNet (_host,  _net) ) . 
explain (hostNet (Host,  Network) ,  Text) 
fmt_wr ite_string (Text, 

"The  host  %S  is  attached  to  network  %S.", 
args (Host, Network) ) . 

primitive (routeEntry (  router,  initnet,  targetnet,  protocol, 

_port) ) . 

explain (routeEntry (Router ,  InitNet,  TargetNet,  Protocol,  Port),  Text) 
fmt_wr ite_string (Text, 

"Router  %S  has  a  rule  which  allows  communication  using  protocol  %S 
to 

destination  port  %S  from  subnet  %S  to  subnet  %S.", 
args (Router,  Protocol,  Port,  InitNet,  TargetNet) ) . 

/*******************************************************/ 

/****  Derived  predicates  *****/ 

y^******************************************************/ 

derived (route (_initnet,  _targetnet,  _protocol,  _port) ) . 
explain (route (InitNet,  TargetNet,  Protocol,  Port),  Text) 
fmt_wr ite_string (Text, 

"A  route  exists  using  protocol  %S  from  subnet  %S  to  subnet  %S 
to  destination  port  %S.", 
args (Protocol,  InitNet,  TargetNet,  Port)). 

derived (had (_ihost,  _thost,  _protocol,  _port) ) . 
explain (had (InitHost,  TargetHost,  Protocol,  Port),  Text) 
fmt_write_string (Text, 

"Host  %S  can  initiate  %S  communications  to  Host  %S  on  port  %S.", 
args  (InitHost,  Protocol,  Port,  TargetHost)). 
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Net_rules.P  listing: 

%  Copyright  (C)  2006  Defence  R&D  Canada 

%  MulVAL  interaction  rules  for  mapping  networks. 

%  Author  :  Mike  Froh 

table  route/4. 

: -  table  hacl/4 . 

/******  Route  Section  *******/ 

interaction_rule ( 

(route (InitNet,  TargetNet,  Protocol,  Port) 

routeEntry (Router ,  InitNet,  TargetNet,  Protocol,  Port), 
hostNet (Router, InitNet)  , 
hostNet (Router, TargetNet) )  , 

'Direct  route  between  subnets  through  an  intermediate  router') . 
interaction_rule ( 

(route (InitNet,  TargetNet,  Protocol,  Port) 

route (InitNet,  TransitNet,  Protocol,  Port), 
route  (TransitNet,  TargetNet,  Protocol,  Port)), 

'Transitive  routing  through  an  intermediate  network'). 

/******  HACL  Section  *******/ 

interaction_rule ( 

(had (InitHost,  TargetHost,  Protocol,  Port) 
hostNet  ( InitHost,  InitNet), 
hostNet  (TargetHost,  TargetNet), 

InitNet  \=  TargetNet, 

route  (InitNet,  TargetNet,  Protocol,  Port)), 

'Hosts  can  only  communicate  between  networks  through  a  valid 
route . ' ) . 

interaction_rule ( 

(had  (InitHost,  TargetHost,  _,  _) 
hostNet ( InitHost,  CommonNet) , 
hostNet  (TargetHost,  CommonNet) ) , 

'Hosts  on  same  network  have  no  communication  restrictions.'). 

/*  I  was  thinking  of  automatically  deriving  the  hostNet  predicates 
for  routers/firewalls  from  the  routeEntry  statements.  But  this 
means  we  need  to  define  a  primitive  hostNet  and  a  derived 
hostNetprime  and  render  all  hostNet  to  hostNetprime  while 
deriving  router/f irewall  hostNetprime  from  routeEntry  predicates. 

This  will  not  work  as  currently  defined! 

interaction_rule ( 

(hostNet (Router, Net) 

routeEntry (Router ,  Net,  _,  _,  _) ; 
routeEntry (Router ,  _,  Net,  _,  _) ) , 

'Routers  are  hosts  on  their  network  interfaces. ') . 


*/ 
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net  test.P  listing  showing  the  network  in  : 


/***  Net  A  ***/ 
hostNet(al,  neta) . 
hostNet(a2,  neta). 
hostNet (multi,  neta). 

/***  Net  B  ***/ 
hostNet  (bl,  netb)  . 
hostNet  (b2,  netb). 
hostNet (multi,  netb). 

/***  Net  C  ***/ 
hostNet  (cl,  netc)  . 
hostNet (c2,  netc). 

/***  Net  D  ***/ 
hostNet (dl,  netd) . 


/***  Router  between  nets  A  &  B  ***/ 
hostNet  (routerAB,  neta). 
hostNet (routerAB,  netb). 
routeEntry (routerAB,  neta,  netb,  tcp, 
routeEntry (routerAB,  netb,  neta,  tcp. 


80)  . 
433)  . 


/***  Router  between  nets  B  &  C  &  D  ***/ 
hostNet  (routerBCD,  netb). 
hostNet  (routerBCD,  netc). 
hostNet  (routerBCD,  netd). 

routeEntry (routerBCD,  netb,  netc,  tcp,  80). 

routeEntry (routerBCD,  netb,  netc,  tcp,  433). 

routeEntry (routerBCD,  netb,  netd,  tcp,  80). 

routeEntry (routerBCD,  netc,  netd,  tcp,  80). 


/***  test  entering  a  derived  predicate  ***/ 

/*  derived  route  predicate  was  ignored  in  mulVAL 
route (neta, netd, udp, 500) . 

*/ 
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The  had/ 4  for  the  network  in  Figure  1  were  derived  using  the  following  XSB 
command: 

stdout2file (visualize (had ( Init, Target, Protocol, Port) , text) , 'attack . tx 

t'  )  . 

The  output  file  was  pretty  printed  using  the  following  bash  command  line: 

cat  attack.txt  |  grep  had  |  sed  1  s/ .  *\ (had  ( .  * )  \ )  .  */\l/  1  |  sed 

' s/_h [0-9 ] */Any/g '  |  sort  >attack_pp . txt 

The  131  had/ 4  rules  derived  were  as  follows: 


had  (al,al,Any,Any) 

had  (al,a2,Any,Any) 

had  (al,bl,  tcp,  80) 

had  (al,b2,  tcp,  80) 

had  (al,  cl,  tcp,  80) 

had  (al,  c2,  tcp,  80) 

had  (al,dl,  tcp,  80) 

had  (al , multi ,  Any ,  Any) 

had  (al, multi,  tcp,  8  0) 

had  (al ,  routerAB,  Any,  Any) 

had  (al,  routerAB,  tcp,  80) 

had  (al,  routerBCD,  tcp,  80) 

had  (a2,al,Any,Any) 

had  (a2 ,  a 2 ,  Any,  Any) 

had  (a2,bl,  tcp,  80) 

had  (a2,b2,  tcp,  80) 

had  (a2,  cl,  tcp,  80) 

had  (a2,  c2,  tcp,  80) 

had  (a2,dl,  tcp,  80) 

had  (a2 , multi ,  Any ,  Any) 

had  (a2, multi,  tcp,  8  0) 

had  (a2 ,  routerAB,  Any,  Any) 

had  (a2,  routerAB,  tcp,  80) 

had  (a2,  routerBCD,  tcp,  80) 

had  (bl,al,  tcp,  4  33) 

had  (bl,a2,  tcp,  433) 

had  (bl,bl.  Any,  Any) 

had  (bl,b2.  Any,  Any) 

had  (bl,  cl,  tcp,  4  33) 

had  (bl,  cl,  tcp,  80) 

had  (bl,  c2,  tcp,  433) 

had  (bl,  c2,  tcp,  80) 

had  (bl,dl,  tcp,  80) 

had  (bl , multi ,  Any ,  Any ) 

had  (bl, multi,  tcp,  4  33) 

had  (bl ,  routerAB,  Any,  Any) 

had  (bl,  routerAB,  tcp,  433) 

had  (bl ,  routerBCD,  Any,  Any) 

had  (bl,  routerBCD,  tcp,  433) 

had  (bl,  routerBCD,  tcp,  80) 

had  (b2,al,  tcp,  433) 

had  (b2,a2,  tcp,  433) 
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had  (b2,bl.  Any,  Any) 
had  (b2 ,  b2 ,  Any,  Any) 
had  (b2,  cl,  tcp,  433) 
had  (b2,  cl,  tcp,  80) 
had  (b2,  c2,  tcp,  433) 
had  (b2,  c2,  tcp,  80) 
had  (b2,dl,  tcp,  80) 
had  (b2 , multi ,  Any ,  Any) 
had  (b2, multi,  tcp,  4  33) 
had  (b2 ,  routerAB,  Any,  Any) 
had  (b2 ,  routerAB,  tcp,  433) 
had  (b2 ,  routerBCD,  Any,  Any) 
had  (b2,  routerBCD,  tcp,  433) 
had  (b2,  routerBCD,  tcp,  80) 
had  (cl,  cl.  Any,  Any) 
had  (cl,  c2.  Any,  Any) 
had  (cl,dl,  tcp,  80) 
had  ( cl ,  routerBCD,  Any,  Any) 
had  (cl,  routerBCD,  tcp,  80) 
had  (c2,  cl.  Any,  Any) 
had  ( c2 ,  c2 ,  Any,  Any) 
had  (c2,dl,  tcp,  80) 
had  ( c2 ,  routerBCD,  Any,  Any) 
had  (c2,  routerBCD,  tcp,  80) 
had  (dl,dl,Any,Any) 
had  (dl ,  routerBCD,  Any,  Any) 
had  (multi,  al ,  Any ,  Any ) 
had  (multi,  al,  tcp,  433) 
had  (multi,  a2 ,  Any ,  Any) 
had  (multi,  a2,  tcp,  4  33) 
had  (multi, bl, Any , Any) 
had  (multi,bl,tcp,80) 
had  (multi,  b2 ,  Any ,  Any) 
had  (multi,  b2 ,  tcp,  8  0) 
had  (multi,  cl,  tcp,  433) 
had  (multi,  cl,  tcp,  80) 
had  (multi,  c2,  tcp,  4  33) 
had  (multi,  c2,  tcp,  8  0) 
had  (multi,  dl ,  tcp,  8  0) 
had  (multi, multi.  Any,  Any) 
had  (multi, multi,  tcp,  433) 
had  (multi, multi,  tcp,  80) 
had  (multi,  routerAB,  Any ,  Any) 
had  (multi,  routerAB,  tcp,  433) 
had  (multi,  routerAB,  tcp,  80) 
had  (multi,  routerBCD,  Any,  Any) 
had  (multi,  routerBCD,  tcp,  433) 
had  (multi,  routerBCD,  tcp,  80) 
had  ( routerAB,  al ,  Any,  Any) 
had  (routerAB, al,  tcp,  433) 
had  ( routerAB,  a2 ,  Any,  Any) 
had  (routerAB,  a2,  tcp,  433) 
had  ( routerAB,  bl ,  Any,  Any) 
had  (routerAB, bl,  tcp,  80) 
had  ( routerAB,  b2 ,  Any,  Any) 
had  (routerAB, b2,  tcp,  80) 
had  (routerAB,  cl,  tcp,  433) 
had  (routerAB,  cl,  tcp,  80) 
had  (routerAB,  c2,  tcp,  433) 
had  (routerAB,  c2,  tcp,  80) 
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had  (routerAB,dl,  tcp,  80) 
had  ( routerAB, multi ,  Any ,  Any) 
had  (routerAB, multi,  tcp,  433) 
had  (routerAB, multi,  tcp,  80) 
had  ( routerAB,  routerAB,  Any,  Any) 
had (routerAB, routerAB, tcp, 433) 
had  (routerAB,  routerAB,  tcp,  80) 
had (routerAB, routerBCD, Any , Any ) 
had (routerAB, routerBCD, tcp, 433) 
had (routerAB, routerBCD, tcp, 80) 
had  (routerBCD,  al,  tcp,  433) 
had  (routerBCD,  a2,  tcp,  433) 
had  ( routerBCD,  bl ,  Any,  Any) 
had  ( routerBCD,  b2 ,  Any,  Any) 
had  (routerBCD,  cl, Any, Any) 
had  (routerBCD,  cl,  tcp,  433) 
had  (routerBCD,  cl,  tcp,  80) 
had  (routerBCD,  c2, Any, Any) 
had  (routerBCD,  c2,  tcp,  433) 
had  (routerBCD,  c2,  tcp,  80) 
had  ( routerBCD,  dl ,  Any,  Any) 
had  (routerBCD,  dl,  tcp,  80) 
had  ( routerBCD, multi.  Any,  Any) 
had  (routerBCD, multi,  tcp,  433) 
had (routerBCD, routerAB, Any , Any ) 
had (routerBCD, routerAB, tcp, 433) 
had  (routerBCD,  routerBCD,  Any,  Any) 
had  (routerBCD,  routerBCD,  tcp,  433) 
had  (routerBCD,  routerBCD,  tcp,  80) 
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